Carsharing system and carsharing method

ABSTRACT

A carsharing system includes circuitry configured to: receive, from a user, a usage request for requesting a reservation for use of a vehicle which is supplied for a vehicle rental service; permit the reservation for use of the vehicle when the reception unit receives the usage request and no reservation for use of the vehicle has been made at time of receiving the usage request; and give, when the reservation for use of the vehicle is determined, a permission for locking or unlocking by using electronic information to the user at a date and a time on which the vehicle is used.

INCORPORATION BY REFERENCE

The present application is a continuation of U.S. patent applicationSer. No. 16/851,619 filed Apr. 17, 2020, which is a continuation of U.S.patent application Ser. No. 16/196,138 filed Nov. 20, 2018, which claimsthe benefit of priority of Japanese Patent Application No. 2017-255029filed Dec. 28, 2017, each of which is incorporated by reference hereinit its entirety.

BACKGROUND 1. Technical Field

The disclosure relates to a carsharing system and a carsharing method.

2. Description of Related Art

Recently, a trunk-sharing system in which a trunk (hereinafter referredto as a cargo compartment) of a vehicle which is designated by a user isused as a pickup and delivery place of a delivery object has beendeveloped as means for efficiently performing pickup and delivery of adelivery object between a user of a pickup and delivery service and apickup and delivery agent. For example, Japanese Unexamined PatentApplication Publication No. 2006-206225 (JP 2006-206225 A) disclosesthat a business communication device mounted in a vehicle of a homedelivery company and a baggage-receiving vehicle which is registered anddesignated as a delivery destination by a receiver perform mutualauthentication and a delivery object is accommodated in a trunk of thebaggage-receiving vehicle at the time of pickup and delivery of adelivery object. Accordingly, even when the receiver is absent, thebaggage-receiving vehicle can alternatively receive baggage.

SUMMARY

In addition to a service in which a cargo compartment and a passengercompartment of a host vehicle (hereinafter a cargo compartment and apassenger compartment are collectively referred to as the interior of avehicle) are used as a delivery destination of baggage as in the relatedart, various services in which a host vehicle, the interior of a vehicleof a specific person, or the interiors of a plurality of vehicles ownedby a plurality of persons are used by the specific person or shared by aplurality of persons are conceivable. When the interior of a vehicle isused by more persons or shared by a plurality of persons, the vehiclecan be used for various applications in addition to reception ofbaggage.

However, the configuration in the related art is merely a configurationin which it is possible to receive the baggage by a receiverdesignating, as a delivery destination, a vehicle which has beenregistered in advance by the receiver. Therefore, the disclosureprovides a carsharing system in consideration with movement of a vehiclein a case where the interior of the vehicle is used by more persons orthe interior of the vehicle is shared by a plurality of persons.

A carsharing system according to a first aspect of the disclosureincludes circuitry configured to: receive, from a user, a usage requestfor requesting a reservation for use of a vehicle which is supplied fora vehicle rental service; permit the reservation for use of the vehiclewhen the circuitry receives the usage request and no reservation for useof the vehicle has been made at time of receiving the usage request; andgive, when the reservation for use of the vehicle is determined, apermission for locking or unlocking by using electronic information tothe user at a date and a time on which the vehicle is used. According tothis aspect, a reservation for use of the vehicle rental service ispermitted at a scheduled date and time at which a usage request for avehicle has not been issued, and a scheduled rental user can use thevehicle.

In the aspect, the usage request may include a desired rental schedulewhich is a schedule in which the user desires rental of the vehicle, andthe circuitry may be configured to: store reservation scheduleinformation indicating a status of the reservation for use of thevehicle; acquire movement schedule information indicating a movementschedule of the vehicle; and provide information on vehicle of whichboth the reservation schedule information and the movement scheduleinformation satisfy the desired rental schedule.

According to this aspect, since the management unit provides informationon an available vehicle in consideration of both the reservationschedule information and the movement schedule information of vehicles,it is possible to provide a carsharing system in consideration withmovement of a vehicle when a person other than an owner of the vehicleuses the vehicle or the vehicle is shared by a plurality of persons.Here, when the interior of a vehicle is rented, the interior of thevehicle includes at least one of a cargo compartment (also referred toas a trunk) and a passenger compartment. The passenger compartment is aspace in which an occupant sits.

In the aspect, the desired rental schedule may include a scheduledtransportation date and time, transportation of baggage being planned tobe performed at the scheduled transportation date and time, and thecircuitry may be configured to: select a selected vehicle which isavailable at the scheduled transportation date and time; and set areservation for use of the selected vehicle at the scheduledtransportation date and time in the reservation schedule information.The circuitry may be configured to control transmitting, to a terminalof a service user associated with the transportation of the baggage,information for identifying the selected vehicle and access permissioninformation for permitting an access to interior of the selectedvehicle.

According to this aspect, since the management unit reserves theinterior of a vehicle in consideration of both the reservation scheduleinformation and the movement schedule information of vehicles, it ispossible to restrain changes of reservations and to enhance a likelihoodthat transportation of baggage will be smoothly performed.

In the aspect, the usage request may include receiver terminalinformation for specifying an address of a terminal of a receiver whoreceives the baggage, and the circuitry may be configured to controltransmitting, to the terminal of the receiver, the information foridentifying the selected vehicle and the access permission informationfor permitting an access to the interior of the selected vehicle.

According to this aspect, the access permission information can betransmitted to the terminal of the receiver who receives the baggage.Furthermore, an access to the interior of the selected vehicle by thereceiver who receives the baggage can be permitted.

In the above aspect, the vehicles which are supplied for the vehiclerental service may be grouped based on geographical positionrelationships correlated with the vehicles respectively, and thecircuitry may be configured to: determine one vehicle of the vehicles asan alternative vehicle, the one vehicle belonging to same group as avehicle which is a transportation destination when a notification isreceived from the terminal of the service user, the notificationindicating that an over-capacity has occurred, the over-capacity being asituation in which baggage to be transported is not able to beaccommodated in the interior of the vehicle which is the transportationdestination; and control transmitting, to the terminal of the serviceuser, information for identifying the alternative vehicle and accesspermission information for permitting an access to the interior of thealternative vehicle.

According to this aspect, in the carsharing system, even when anover-capacity in which baggage cannot be accommodated in the interior ofthe vehicle which is a transportation destination of the baggage hasoccurred, it is possible to secure an alternative vehicle near thevehicle which is the transportation destination and to enhance alikelihood that the transportation will be smoothly performed.

In the above aspect, the vehicles which are supplied for the vehiclerental service may be grouped based on geographical positionrelationships correlated with the vehicles, the circuitry may beconfigured to: receive, from a terminal of an owner of the vehicle, achange request for changing a movement schedule of the vehicle relatedto a period overlapping with a rental schedule, from a first plan to asecond plan, the rental schedule being a schedule in which rental of thevehicle is reserved, the first plan being a plan that the vehicle is notto move, and the second plan being a plan that the vehicle is to move;determine one vehicle of the vehicles as an alternative vehicle, the onevehicle belonging to same group as a vehicle which is a transportationdestination; and control transmitting, to the terminal of the serviceuser, information for identifying the alternative vehicle and accesspermission information for permitting an access to interior of thealternative vehicle.

According to this aspect, in the carsharing system, even when a movementschedule of an owner of a vehicle has changed, the owner of the vehiclecan reduce inconvenience of a user who has reserved the vehicle andenhance a likelihood that movement using the vehicle will be able to beperformed as much as possible.

In the above aspect, the movement schedule information may be generatedbased on activity schedule information in which an activity schedule ofan owner of the vehicle is set.

According to this aspect, in the carsharing system, it is possible toeasily set a movement schedule using an activity schedule of an owner ofa vehicle.

In the above aspect, the circuitry may configured to offer apredetermined incentive to an owner of the vehicle who has permittedprovision of the movement schedule information or an owner who hasagreed to acceptance of movement limitation of a vehicle.

According to this aspect, with the carsharing system, it is possible toenhance a likelihood that an owner of a vehicle will provide a movementschedule of the vehicle and to enhance accuracy of information on anavailable vehicle. With the carsharing system, it is possible to enhancea likelihood that an owner of a vehicle will accept limitation ofmovement of the vehicle and to enable smooth operation of the carsharingsystem.

In the above aspect, the circuitry may be configured to determineincentive points offered to an owner of a reserved vehicle based on afirst ratio or a second ratio, the reserved vehicle being a vehicle ofwhich rental is reserved based on the reservation schedule information,the first ratio being a ratio of the number that rental of the vehiclein accordance with the reservation schedule information is performed toa reserved number, the second ratio being a ratio of the number that therental of the vehicle in accordance with the reservation scheduleinformation is not performed to the reserved number, and the reservednumber being the number that rental of the vehicle is reserved based onthe reservation schedule information.

According to this aspect, in the carsharing system, since it is curbedchange of a movement schedule of a vehicle by an owner of the vehicle,it is possible to enable a service user to stably use the interior ofthe vehicle.

In the above aspect, the circuitry may be configured to provideinformation on vehicles in a recommended order in which a first vehicleor a second vehicle has priority when a plurality of vehicles satisfiesthe desired rental schedule, the first vehicle being a vehicle of anowner who has permitted provision of the movement schedule information,and the second vehicle being a vehicle of an owner who has highincentive points.

In a vehicle of which provision of movement schedule information hasbeen permitted, there is a high likelihood that a reservation for rentalof the interior of the vehicle will be performed as scheduled. In avehicle of an owner with a high incentive point, there is a highlikelihood that the owner will observe the movement schedule informationand a reservation for rental of the interior of the vehicle (alsoreferred to as a reservation for use of a service) will be performed asscheduled. Accordingly, according to this aspect, it is possible toenable a user to stably use the interior of the vehicle.

In the above aspect, the usage request may include information forspecifying geographical conditions in which the vehicle rental serviceis provided, and the circuitry may be configured to provide informationon vehicles which satisfy the geographical conditions with reference toposition information of the vehicles which are supplied for the vehiclerental service. Accordingly, the carsharing system can provide a serviceby performing a process with a limitation to vehicles satisfying thegeographical conditions in the vehicle rental service.

The carsharing system according to a second aspect of the disclosureincludes circuitry configured to: store groups of a plurality ofvehicles which are formed based on geographical position relationshipscorrelated with the vehicles, the vehicles being supplied for a vehiclerental service; receive a usage request including a desired rentalregion of a vehicle which is supplied for the vehicle rental service;specify a group of vehicles associated with the desired rental region inresponse to the usage request; and provide information on the group ofvehicles associated with the desired rental region.

According to this aspect, since information of groups of vehicles whichare formed based on addresses is provided in response to the serviceusage request for the interior of a vehicle including a desired rentalregion, a user can reserve a group of vehicles without clearly reservingindividual vehicles, and can be provided with a service using a vehiclebelonging to the group after an actual schedule of the service or thelike has been clarified.

In the above aspect, the usage request may be a service usage requestfor using a vehicle as a transportation destination of baggage. Thecircuitry may be configured to select, as a selected vehicle, onevehicle of the vehicles belonging to the group in response to a requestfor an access to the group which is issued from a terminal of a serviceuser in charge of transportation of the baggage within a predeterminedperiod from a scheduled transportation date and time at whichtransportation of the baggage is performed after the scheduledtransportation date and time has been determined, and to controltransmitting information for identifying the selected vehicle and accesspermission information for permitting an access to the interior of theselected vehicle to the terminal of the service user.

According to this aspect, a group of vehicles can be specified as atransportation destination of baggage, and a vehicle rental serviceusing one vehicle of the vehicles belonging to the group can be providedafter a scheduled transportation date and time at which transportationof baggage is performed has been determined. Accordingly, a user can beprovided with a flexible service using a group of vehicles which isformed based on addresses correlated with the vehicles. According toanother aspect of the disclosure, there is provided a method causing acomputer to perform processes corresponding to the above-mentionedaspects of the carsharing system.

With the above-mentioned carsharing system, it is possible to reduceoccurrence of problems with movement of a vehicle when the interior ofthe vehicle is used by more persons or the interior of the vehicle isshared by a plurality of persons.

BRIEF DESCRIPTION OF THE DRAWINGS

Features, advantages, and technical and industrial significance ofexemplary embodiments of the disclosure will be described below withreference to the accompanying drawings, in which like numerals denotelike elements, and wherein:

FIG. 1 is a diagram illustrating a configuration of a carsharing systemaccording to a first embodiment;

FIG. 2 is a diagram illustrating hardware configurations of an onboarddevice, a user terminal, an owner terminal, a central server, and arental management server;

FIG. 3 is a diagram illustrating specific elements that performprocesses of the rental management server;

FIG. 4 is a diagram illustrating a configuration of a vehicleregistration table;

FIG. 5 is a diagram illustrating a configuration of a cluster definitiontable;

FIG. 6 is a diagram illustrating a configuration of a cluster membertable;

FIG. 7 is a diagram illustrating a configuration of an ownerregistration table;

FIG. 8 is a diagram illustrating a configuration of an owner evaluationtable;

FIG. 9 is a diagram illustrating a configuration of a user registrationtable;

FIG. 10 is a diagram illustrating a configuration of movement scheduleinformation;

FIG. 11 is a diagram illustrating a configuration of vehicle interiorrental schedule information;

FIG. 12 is a flowchart illustrating a process routine which is performedby a management unit;

FIG. 13 is a flowchart illustrating a detailed flow of a vehicleschedule searching process;

FIG. 14 is a flowchart illustrating a flow of a vehicle registrationreceiving process;

FIG. 15 is a flowchart illustrating a flow of a vehicle renting process;

FIG. 16A is a former sequence diagram of an information system accordingto a second embodiment;

FIG. 16B is a later sequence diagram of the information system accordingto the second embodiment;

FIG. 17 is a flowchart illustrating a flow of an over-capacityprocessing process;

FIG. 18 is a flowchart illustrating a flow of processes which areperformed by a rental management server having received a notificationdue to change of a movement schedule;

FIG. 19A is sequence diagram of an information system according to athird embodiment; and

FIG. 19B is sequence diagram of the information system according to thethird embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

Hereinafter, an information system according to an embodiment of thedisclosure will be described. The embodiments which are described belowexemplify aspects of the disclosure and the technical scope of thedisclosure is not limited to the following aspects.

First Embodiment

An information system (hereinafter also referred to as a carsharingsystem 1) according to a first embodiment and a carsharing method ofcausing a computer of the information system to perform processes(steps) will be described below with reference to FIGS. 1 to 15.

<Image of Processing>

The information system according to this embodiment provides a serviceof supporting common use of the interior of a vehicle by a plurality ofusers and an owner of the vehicle. In this embodiment, an owner of avehicle registers his or her vehicle in the information system andprovides the vehicle as a vehicle of which the interior can be used by asingle user or a plurality of users. The information system discloses anunoccupied state or a reserved state of the vehicle to users through aweb site. A user of a vehicle accesses the web site, checks anunoccupied time of the vehicle, and reserves a time in which theinterior of the vehicle is used. There are various methods of using theinterior of a vehicle, and an example thereof is use of the interior ofa vehicle as a delivery destination of baggage. That is, in thisembodiment, the interior of a vehicle is used, for example, as adelivery box or a pickup box in home delivery. Accordingly, a deliveryperson of a home delivery company and a receiver who receives deliveredbaggage are assumed as users of this service. Therefore, a deliveryperson of a home delivery company is an example of a service user. Inthis embodiment, the service is not limited to delivery, and alsoincludes pickup. Delivery and pickup can be said to be transportation.Accordingly, a service user also includes a person in charge of pickupof a home delivery company. In addition to a staff member or an employeeof a home delivery company, examples of the service user include personsin charge of other services such as a person in charge of milk delivery,a person in charge of newspaper delivery, a person in charge of postaldelivery, and an article exchange service provider. Examples of theservice user include general citizens or consumers when the generalcitizens or consumers deliver, receive, or give and receive baggage, inaddition to a service provider who provides a service as business. Inthe following description, “delivery” is exemplified as an activitywhich is performed by a service user in the carsharing service, butexamples of the service user include employees who work for variousbusinesses, general consumers, and citizens.

When the interior of a vehicle is used as a delivery destination ofbaggage, baggage under delivery may not be able to be accommodatedtherein depending on a relationship between the size of baggage underdelivery and the capacity of the interior of the vehicle or arelationship between the size of baggage under delivery and a remainingcapacity of the interior of the vehicle other than baggage which hasbeen already delivered and stored. An aspect of this embodiment reducesthis problem. That is, the information system groups supplied vehiclesbased on geographical position relationships such as addresses ordistances between the vehicles. Grouping is referred to as clustering. Agroup of vehicles is referred to as a cluster. When baggage underdelivery cannot be accommodated in the interior of a vehicle to whichthe baggage is scheduled to be delivered, the information systemdetermines another vehicle belonging to the same group as an alternativedelivery destination and notifies a delivery person and a receiver ofthe determination via a terminal of the delivery person. That is, theinformation system manages, for example, the interiors of a plurality ofvehicles which are supplied in one region as a cluster and flexiblycopes with sizes or volumes of delivery objects.

In another aspect of this embodiment, a movement schedule indicating aschedule in which a vehicle will be moved by an owner or the like ismanaged in addition to a reservations schedule for use of the interiorof the vehicle by a user as the premise of scheduling of a reservationfor the interior of a vehicle. That is, an owner of a vehicle can supplya movement schedule of the vehicle in supplying the vehicle. Theinformation system manages both a use schedule of the interior of avehicle and a movement schedule of the vehicle and provides a vehiclewhich can satisfy a user's desire to the user. Here, a movement scheduleincludes, for example, a schedule in a case where an owner of a vehicledoes not drive the vehicle but the vehicle moves by an automatic drivingfunction and a schedule in a case where a vehicle moves by unmanneddriving, in addition to a case where an owner of a vehicle drives thevehicle.

Since a service quality is improved due to this information system, theinformation system offers predetermined incentive points to an owner whoprovides a movement schedule of a vehicle. When a user can use theinterior of a vehicle as scheduled without any inconvenience byobserving the movement schedule of the vehicle, the information systemoffers predetermined incentive points to the owner of the vehicle.

<System Configuration>

FIG. 1 is a diagram illustrating a configuration of the informationsystem according to the first embodiment. In the example illustrated inFIG. 1, a carsharing system 1 includes an onboard device 10A which isinstalled in a vehicle 10, a user terminal 200, an owner terminal 210, acentral server 400, a rental management server 410, and an externalserver 420. The onboard device 10A, the user terminal 200, the ownerterminal 210, the central server 400, the rental management server 410,and the external server 420 are connected to each other via a networkN1. The onboard device 10A is connected to the user terminal 200 or theowner terminal 210 via a network N2 including a short-range wirelesscommunication network. More specifically, the user terminal 200 is usedas a deliverer terminal 220 of a home delivery company or a receiverterminal 230 which is used by a receiver of baggage.

The rental management server 410 receives registration of a vehiclewhich is supplied for a carsharing service from the owner terminal 210.At the time of registration of a vehicle, the rental management server410 receives information for identifying the vehicle (such as aregistration number, a vehicle model, and a color of the vehicle). Atthe time of registration of a vehicle, the rental management server 410checks whether a movement schedule of the vehicle has been provided viathe owner terminal 210. The movement schedule of the vehicle is providedby an owner having issued a response indicating that the movementschedule is to be provided. The owner of the vehicle can registerinformation on the vehicle which is supplied and the movement scheduleof the vehicle of the owner having agreed to the provision through apredetermined application program (hereinafter simply referred to as anapplication) which is installed in the owner terminal 210.

The rental management server 410 provides a vehicle interior rentalschedule to the user terminal 200 through the web site in order toenable a reservation for the interior of the vehicle which is registeredby the owner terminal 210. A user can specify a vehicle satisfying theuser's desired use conditions, for example, by inputting a desired useregion, a desired use date and time, or the like through thepredetermined application installed in the user terminal 200. Asdescribed above, in the information system, vehicles are grouped intogroups which are called clusters based on regions, and the informationsystem determines whether a desired use region is possible based on theclusters of vehicles. The information system determines whether adesired use date and time is satisfied by comparison based on both therental schedules of the vehicles and the movement schedules of thevehicles. When there is a vehicle satisfying the user's desired useconditions, the rental management server 410 presents the vehicle to theuser terminal 200, receives an acknowledgement from the user terminal200, and then registers the vehicle in a cargo compartment rentalschedule.

<Hardware Configuration>

FIG. 2 is a diagram illustrating hardware configurations of the onboarddevice 10A, the user terminal 200, the owner terminal 210, the centralserver 400, and the rental management server 410. The configurations ofthe deliverer terminal 220 and the receiver terminal 230 are the same asthat of the user terminal 200 and thus are not illustrated in FIG. 2.The configuration of the external server 420 is the same as that of thecentral server 400 and thus is not illustrated in FIG. 2. In thisembodiment, it is assumed that the disclosure is applied to a vehicle 10which performs locking and unlocking via a key unit 100 disposed in theonboard device 10A. The key unit 100 includes the same wirelessinterface as an electronic key (hereinafter referred to as a portableunit) which is called a smart key and performs communication with anexisting locking/unlocking device 300 of the onboard device 10A. Forexample, a user can lock and unlock the vehicle 10 without using aphysical key by performing authentication with the key unit 100 usingterminal authentication information stored in the user terminal 200.That is, the key unit 100 performs short-range wireless communicationwith a mobile terminal such as the user terminal 200 or the ownerterminal 210 (hereinafter referred to as a user terminal 200 or thelike) and determines whether the key unit functions as an electronic keyto the vehicle 10 based on the authentication result of the userterminal 200 or the like.

The terminal authentication information which is transmitted from theuser terminal 200 or the like to the key unit 100 is compared withdevice authentication information which is stored in advance in the keyunit 100. When the authentication has succeeded, the user terminal 200or the like is authenticated. When the user terminal 200 or the like isauthenticated, the key unit 100 transmits a key ID of the vehicle 10,which is stored in advance in the key unit 100 and is correlated withauthentication information, to the locking/unlocking device 300 alongwith a locking/unlocking signal. When the key ID received from the keyunit 100 coincides with a key ID which is stored in advance in thelocking/unlocking device 300, the locking/unlocking device 300 locks orunlocks the vehicle 10. The key ID stored in advance in the key unit 100may be encrypted with the authentication information. In this case, whenthe authentication process of the user terminal 200 or the likesucceeds, the key unit 100 can decrypt the key ID with theauthentication information and transmit the decrypted key ID to thelocking/unlocking device 300.

The owner terminal 210 of the owner who is an occupier of the vehicle 10stores master authentication information which can be authenticated bythe key unit 100 and the owner can lock and unlock the vehicle 10 at anytime. Here, “at any time” means that a valid period is not set in themaster authentication information and thus the owner can lock and unlockthe vehicle 10 at any time in this embodiment. On the other hand, at thetime of acquisition of baggage in the interior of the vehicle or thelike, the user terminal 200 receives terminal authentication informationfor unlocking and locking the vehicle 10 from the central server 400 orthe rental management server 410. The user terminal 200 transmits thereceived terminal authentication information to the key unit 100, andthe key unit 100 transmits the key ID of the vehicle 10 stored inadvance in the key unit 100 to the locking/unlocking device 300 whenauthentication of the user terminal 200 by the key unit 100 hassucceeded. The locking/unlocking device 300 locks and unlocks thevehicle 10 when the key ID received from the key unit 100 coincides withthe key ID stored in advance in the locking/unlocking device 300. Thekey unit 100 and the locking/unlocking device 300 operate with electricpower supplied from a battery which is mounted in the vehicle 10. Thekey unit 100 may operate with electric power supplied from a generalbattery in addition to the battery mounted in the vehicle 10.

The locking/unlocking device 300 is a device for locking and unlocking adoor of the vehicle 10 and is an existing device which constitutes apart of a smart keying system. Specifically, the locking/unlockingdevice 300 locks and unlocks the door of the vehicle 10 in accordancewith a locking signal and an unlocking signal which are transmitted froma portable unit carried by a user of the vehicle 10 using radio waves ofa radio frequency (hereinafter referred to as RF) band. Thelocking/unlocking device 300 also has a function of transmitting radiowaves of a low frequency (hereinafter referred to as LF) band fordetecting a portable unit.

In this embodiment, instead of the portable unit carried by the user,the key unit 100 may control locking and unlocking of the door of thevehicle 10 by transmitting and receiving radio waves of an RF band andan LF band to and from the locking/unlocking device 300. In thefollowing description, unless mentioned otherwise, a communicationdestination of the locking/unlocking device 300 is limited to the keyunit 100.

The locking/unlocking device 300 includes an LF transmitter 301, an RFreceiver 302, a comparison ECU 303, a body ECU 304, and a door lockmotor 305. The LF transmitter 301 is means that transmits radio waves ofan LF band (for example, 100 KHz to 300 KHz) for detecting (polling) thekey unit 100. The LF transmitter 301 is incorporated, for example, in acenter console or the vicinity of a steering wheel in a passengercompartment. The RF receiver 302 is means that receives radio waves ofan RF band (for example, 100 MHz to 1 GHz) transmitted from the key unit100. The RF receiver 302 is incorporated at a position in the passengercompartment.

The comparison ECU 303 is a computer that performs control for lockingand unlocking the door of the vehicle 10 (or a door of a cargocompartment or both) based on a signal (a locking signal or an unlockingsignal) transmitted from the key unit 100 using the radio waves of theRF band. The comparison ECU 303 is constituted, for example, by amicrocomputer. In the following description, the locking signal and theunlocking signal are collectively referred to as a locking/unlockingsignal. The term, locking/unlocking signal, represents at least one ofthe locking signal and the unlocking signal.

The comparison ECU 303 authenticates whether the locking/unlockingsignal transmitted from the key unit 100 has been transmitted from arightful device. Specifically, the comparison ECU 303 determines whetherthe key ID included in the locking/unlocking signal coincides with thekey ID stored in advance in a storage unit of the comparison ECU 303.Then, the comparison ECU 303 transmits an unlocking command or a lockingcommand to the body ECU 304 based on the authentication result. Theunlocking command or the locking command is transmitted via an onboardnetwork such as a controller area network (CAN).

The body ECU 304 is a computer that executes body control of the vehicle10. The body ECU 304 has a function of performing unlocking and lockingof the door of the vehicle 10 by controlling the door lock motor 305based on the unlocking command or the locking command received from thecomparison ECU 303. The door lock motor 305 is an actuator that locksand unlocks the door of the vehicle 10 (which includes a cargocompartment in addition to a boarding door and a rear gate). The doorlock motor 305 operates based on a signal transmitted from the body ECU304. The comparison ECU 303 and the body ECU 304 may be embodied as asingle body.

The key unit 100 will be described now. The key unit 100 is a devicethat is disposed at a predetermined position (for example, inside aglove box) in the passenger compartment of the vehicle 10. The key unit100 has a function of authenticating the user terminal 200 or the likeby performing short-range radio communication with the user terminal 200or the like and a function of transmitting the locking/unlocking signalusing radio waves of an RF band based on the authentication result. Thekey unit 100 includes an LF receiver 101, an RF transmitter 102, ashort-range communication unit 103, and a control unit 104.

The LF receiver 101 is means that receives a polling signal transmittedfrom the locking/unlocking device 300 using radio waves of an LF band.The LF receiver 101 includes an antenna for receiving radio waves of anLF band (hereinafter referred to as an LF antenna). The RF transmitter102 is means that transmits a locking/unlocking signal to the key unit100 using radio waves of an RF band.

The short-range communication unit 103 is means that communicates withthe user terminal 200 or the like carried by the user. The short-rangecommunication unit 103 performs communication in a short range (at adistance at which communication can be performed between the inside andthe outside of the vehicle) using a predetermined radio communicationstandard.

In this embodiment, the short-range communication unit 103 performs datacommunication based on a Bluetooth (registered trademark) Low Energystandard (hereinafter referred to as BLE). BLE is a low-energycommunication standard using Bluetooth, and is characterized in thatcommunication can be started immediately when a communication partner isdetected without requiring pairing between devices. In this embodiment,BLE is exemplified, but another radio communication standard can also beused. For example, near field communication (NFC), ultra-wideband (UWB),or WiFi (registered trademark) may be used.

The control unit 104 is a computer that performs short-range radiocommunication with the user terminal 200 via the short-rangecommunication unit 103 and performs control for authenticating the userterminal 200 or the like and control for transmitting alocking/unlocking signal based on the authentication result. The controlunit 104 is constituted, for example, by a microcomputer.

The control unit 104 includes a storage unit 1041 and an authenticationunit 1042. A control program for controlling the key unit 100 is storedin the storage unit 1041. The control unit 104 may realize variousfunctional units including the authentication unit 1042 by causing a CPU(not illustrated) to execute the control program stored in the storageunit 1041. For example, the control unit 104 may realize a function ofreceiving a polling signal transmitted as radio waves of an LF band fromthe locking/unlocking device 300 via the LF receiver 101, a function oftransmitting a locking/unlocking signal as radio waves of an RF band tothe locking/unlocking device 300 via the RF transmitter 102, a functionof processing communication with the user terminal 200 or the like whichis performed by the short-range communication unit 103, and a functionof generating a locking/unlocking signal when authentication of the userterminal 200 or the like by the authentication unit 1042 has succeeded.

The authentication unit 1042 authenticates the user terminal 200 or thelike based on terminal authentication information included in a lockingrequest or an unlocking request (hereinafter collectively referred to asa locking/unlocking request) transmitted from the user terminal 200 orthe like. Specifically, the authentication unit 1042 compares theterminal authentication information transmitted from the user terminal200 or the like with the device authentication information stored in thestorage unit 1041 and determines that the authentication has succeededwhen they have a predetermined relationship. When the terminalauthentication information and the device authentication information donot satisfy the predetermined relationship, the authentication unit 1042determines that the authentication has failed. Here, the predeterminedrelationship includes a case in which the device authenticationinformation stored in the storage unit 1041 and the terminalauthentication information transmitted from the user terminal 200 or thelike coincide with each other, a case in which results of predeterminedprocesses such as encryption and decryption using the two pieces ofauthentication information coincide with each other, and a case in whichthe result of decryption on one of the two pieces of authenticationinformation coincides with that of the other thereof.

When the authentication of the user terminal 200 or the like by theauthentication unit 1042 has succeeded, a locking/unlocking signal whichis generated in response to a request received from the user terminal200 or the like is transmitted to the locking/unlocking device 300 viathe RF transmitter 102. The authentication method which is performed bythe authentication unit 1042 as described above may be a method ofverifying coincidence through simple comparison of authenticationinformation or may be a method using asymmetric ciphers. As describedabove, in the following description of this embodiment, theauthentication information stored in the key unit 100 is referred to asdevice authentication information and the authentication informationtransmitted from the user terminal 200 is referred to as terminalauthentication information. As described above, the key unit 100transmits an ID of an electronic key (hereinafter referred to as a keyID) to the locking/unlocking device 300 along with the locking/unlockingsignal.

The rental management server 410 has a configuration of a generalcomputer. The rental management server 410 includes a processor 411, amain storage unit 412, an auxiliary storage unit 413, and acommunication unit 414. These units are connected to each other via abus. The main storage unit 412 and the auxiliary storage unit 413 arecomputer-readable recording mediums. The hardware configuration of thecomputer is not limited to the example illustrated in FIG. 2, andomission, substitution, and addition of an element may be appropriatelyperformed thereon.

The rental management server 410 can realize functions matching apredetermined purpose by causing the processor 411 to load a programstored in a recording medium into a work area of the main storage unit412 and to execute the program and controlling the constituent units andthe like through execution of the program.

The processor 411 is, for example, a central processing unit (CPU) or adigital signal processor (DSP). The processor 411 controls the rentalmanagement server 410 and performs various information processingoperations. The main storage unit 412 includes, for example, a randomaccess memory (RAM) and a read only memory (ROM). The auxiliary storageunit 413 is, for example, an erasable programmable ROM (EPROM), a harddisk drive (HDD), or a solid state drive (SSD). The auxiliary storageunit 413 can include a removable medium, that is, a portable recordingmedium. Examples of the removable medium include a universal serial bus(USB) memory or a disk recording medium such as a compact disc (CD) or adigital versatile disc (DVD).

The auxiliary storage unit 413 stores various programs, various types ofdata, and various tables on a recording medium in a readable andwritable manner. An operating system (OS), various programs, varioustables, and the like are stored in the auxiliary storage unit 413.Information stored in the auxiliary storage unit 413 may be stored inthe main storage unit 412. Information stored in the main storage unit412 may be stored in the auxiliary storage unit 413.

The communication unit 414 is connected to other devices and controlscommunication between the rental management server 410 and otherdevices. The communication unit 414 is, for example, a local areanetwork (LAN) interface board or a radio communication circuit for radiocommunication. The LAN interface board or the radio communicationcircuit is connected to the network N1 such as the Internet which is apublic communication network.

A sequence of processes which are performed by the rental managementserver 410 can be realized by causing the processor 411 to execute acomputer program (also referred to as software) in the main storage unit412, and at least a part of the sequence of processes may be performedby a hardware circuit.

Similarly to the rental management server 410, the central server 400includes a processor 401, a main storage unit 402, an auxiliary storageunit 403, and a communication unit 404. The processor 401, the mainstorage unit 402, the auxiliary storage unit 403, and the communicationunit 404 are the same as the processor 411, the main storage unit 412,the auxiliary storage unit 413, and the communication unit 414 of therental management server 410 and thus description thereof will not berepeated.

The user terminal 200 and the owner terminal 210 are, for example, asmall computer such as a smartphone, a mobile phone, a tablet terminal,a personal information terminal, or a wearable computer (such as a smartwatch). The owner terminal 210 may be a personal computer (PC) that isconnected to the rental management server 410 via the network N1 such asthe Internet which is a public communication network.

The owner terminal 210 includes a processor 211, a main storage unit212, an auxiliary storage unit 213, a display unit 214, an input unit215, a communication unit 216A, a communication unit 216B, and ashort-range communication unit 216C. The processor 211, the main storageunit 212, and the auxiliary storage unit 213 are the same as theprocessor 411, the main storage unit 412, and the auxiliary storage unit413 of the rental management server 410 and description thereof will notbe repeated. The display unit 214 is, for example, a liquid crystaldisplay (LCD) or an electroluminescence (EL) panel. The input unit 215includes a touch panel and push buttons. The input unit 215 can includean input unit for a video or an image such as a camera or an input unitfor sound such as a microphone. The communication unit 216A is acommunication circuit that is used to access the Internet, for example,via a mobile phone network with a base station as a terminal. Thecommunication unit 216B is a communication circuit that accesses theInternet, for example, via a wireless or wired LAN and performs datacommunication with the rental management server 410 or the like. Theshort-range communication unit 216C is a communication circuit thatperforms short-range communication in accordance with a predeterminedcommunication standard. Examples of the predetermined communicationstandard include BLE and NFC.

Similarly to the owner terminal 210, the user terminal 200 includes aprocessor 201, a main storage unit 202, an auxiliary storage unit 203, adisplay unit 204, an input unit 205, a communication unit 206A, acommunication unit 206B, and a short-range communication unit 206C. Theprocessor 201, the main storage unit 202, the auxiliary storage unit203, the display unit 204, and the input unit 205 are the same as theprocessor 211, the main storage unit 212, the auxiliary storage unit213, the display unit 214, and the input unit 215 of the owner terminal210 and description thereof will not be repeated. The communication unit206A is a communication circuit that accesses the Internet, for example,via a mobile phone network with a base station as a terminal. Thecommunication unit 206B is a radio communication circuit that accessesthe Internet, for example, via a wireless LAN such as WiFi. The userterminal 200 can perform data communication with the rental managementserver 410, the central server 400, or the like via the communicationunit 206B. The short-range communication unit 206C controlscommunication with the vehicle 10 at a relatively short distance inaccordance with a predetermined communication standard. Examples of thepredetermined communication standard include BLE and NFC.

The network N1 is, for example, a global public communication networksuch as the Internet, and a wide area network (WAN) or othercommunication networks may be employed. The network N1 may include atelephone communication network of mobile phones and the like and awireless communication network such as WiFi. The user terminal 200 andthe owner terminal 210 can access the Internet via a telephonecommunication network for mobile phones or the like or a wirelesscommunication network such as WiFi. The network N2 includes acommunication network such as BLE for allowing the user terminal 200 andthe owner terminal 210 to communicate with the onboard device 10A. Theuser terminal 200 and the owner terminal 210 can communicate with theonboard device 10A via a short-range communication network such as BLE.

<Detailed Configuration of Rental Management Server>

FIG. 3 is a diagram illustrating details of elements that perform aprocess routine of the rental management server 410. As illustrated inthe drawing, the rental management server 410 includes a web server F11,an owner managing unit F12, a vehicle managing unit F13, a scheduleinformation acquiring unit F14, a rental managing unit F15, and areception unit F16 as processing units that perform the process routine.The rental management server 410 also includes an owner DB D11, avehicle DB D12, a user DB D13, a movement schedule DB D14, and a rentalschedule DB D15 as databases (DB) that manage a variety of information.As described above, the processor 411 of the rental management server410 serves as the processing units illustrated in FIG. 3 using acomputer program loaded into the main storage unit 412. At least a partof the processing units may be embodied by a hardware circuit. Theprocessor 411 constructs the DBs in the main storage unit 412 and theauxiliary storage unit 413. The DBs may be constructed on a server fordata input and output (not illustrated) which is connected to the rentalmanagement server 410 via the network N1.

The web server F11 is a computer program which is loaded into the mainstorage unit 412 and is executed by the processor 411. In the followingdescription, when the processor 411 performs processing in accordancewith a computer program, it may be simply described that the computerprogram performs processing. The web server provides informationassociated with a carsharing service to a user in cooperation with theprocessing units and the DBs illustrated in FIG. 3. For example, the webserver F11 may provide schedule information of vehicles which aresupplied for the carsharing service or the like based on information inthe rental schedule DB D15. The web server F11 receives an input fromthe owner terminal 210 or the user terminal 200 and sends the inputinformation to the processing units.

The owner managing unit F12 receives information on an owner of avehicle from the owner terminal 210 or a terminal (not illustrated)installed in a vehicle shop via the web server F11 and stores thereceived information in the owner DB D11. The vehicle managing unit F13receives information on vehicles which are supplied for the carsharingservice from the owner terminal 210 or a terminal installed in a vehicleshop via the web server F11 and stores the received information in thevehicle DB D12.

The schedule information acquiring unit F14 receives vehicle movementschedule information for an owner from the owner terminal 210 and storesthe received movement schedule information in the movement schedule DBD14. The schedule information acquiring unit F14 may extract movementschedule information from an activity schedule DB D16 of an owner whichis managed by the external server 420 by designation from the ownerterminal 210. For example, the schedule information acquiring unit F14can set time periods of an activity schedule including terms fordesignating driving of a vehicle, for example, “driving” or“transportation,” in the owner activity schedule stored in the activityschedule DB D16 as time periods in which the vehicle is driven in theactivity schedule DB D16. When “staying home” is set in the activityschedule DB D16, the schedule information acquiring unit F14 canregister a record indicating that there is no movement schedule in themovement schedule DB D14.

The activity schedule DB D16 can include scheduled activity items suchas “drive,” “operation,” and “transportation” in addition to scheduledactivity items defining an activity schedule such as “conference,”“business trip,” and “visitor.” Such scheduled activity items can beselected by a user using a setting menu of a graphical user interface(GUI) of the activity schedule DB D16 or the like and can be set in theactivity schedule DB D16. The activity schedule DB D16 can set a vehicleID for identifying a vehicle which is used in the scheduled activityitems such as “drive,” “operation,” and “transportation.” The activityschedule DB D16 can include a conversion table in which a vehicle ID inthe activity schedule DB D16 is correlated with a vehicle ID foridentifying the vehicle in the vehicle DB D12 (see FIG. 4). When theactivity schedule DB D16 has such a configuration, the scheduleinformation acquiring unit F14 can more satisfactorily extract amovement schedule of a vehicle (which includes automatic driving or thelike) for an owner from the activity schedule DB D16.

That is, the schedule information acquiring unit F14 acquires movementschedule information indicating movement schedules of vehicles which aresupplied for a vehicle interior rental service by input from the ownerterminal 210 or extraction of a term from the activity scheduleinformation of owners. Accordingly, the movement schedule information isgenerated, for example, based on activity schedule information in whichactivity schedules of owners of vehicles are set.

The reception unit F16 receives an input of a user from the userterminal 200 via the web server F11. The rental managing unit F15registers information for identifying the user in the user DB D13 basedon the input received by the reception unit F16. The reception unit F16receives a service usage request including desired rental conditionssuch as a region desired by a user and a desired rental date and time.The rental managing unit F15 compares the desired rental conditionsreceived by the reception unit F16 with the rental schedule DB D15 andthe movement schedule DB D14, selects vehicles which satisfy thereceived desired rental conditions, and presents a list of the selectedvehicles to the user terminal 200. The reception unit F16 receives auser's selecting operation on the presented list of vehicles. The rentalmanaging unit F15 registers a rental schedule of the vehicle selected bythe user in the rental schedule DB D15 based on the user's desiredrental date and time. Here, the desired rental date and time is anexample of a desired rental schedule. Accordingly, the reception unitF16 receives a usage request including a desired rental schedule of thevehicle interior in the vehicle rental service, and the rental managingunit F15 provides information on the vehicle satisfying the desiredrental schedule in both the reservation schedule information and themovement schedule information. As described above, in the service usagerequest received by the reception unit F16, a region in which a parkinglot in which a vehicle to be rented is housed is located may bedesignated. The rental managing unit F15 is an example of a managementunit.

The external server 420 stores, for example, the activity schedule DBD16 in which activity schedules of owners are stored. The externalserver 420 provides the activity schedule of the owner to the scheduleinformation acquiring unit F14 in response to a request from the rentalmanagement server 410.

<Configuration of Database>

Data structures of the DBs in the information system will be describedbelow. As illustrated in FIG. 3, the owner DB D11 includes a pluralityof tables such as an owner registration table and an owner evaluationtable. The vehicle DB D12 includes a plurality of tables such as avehicle registration table, a cluster definition table, and a clustermember table. On the other hand, the user DB D13 includes a userregistration table, the movement schedule DB D14 includes movementschedules of vehicles, and the rental schedule DB D15 includes vehicleinterior rental schedules.

FIG. 4 is a diagram illustrating a configuration of the vehicleregistration table of the vehicle DB D12. The vehicle registration tableis a table in which vehicles supplied for a carsharing service using theinformation system according to this embodiment are registered. When anowner of a vehicle supplies the vehicle for the carsharing service, theowner inputs information for identifying the vehicle via a screen (forexample, a GUI on the web site) which is provided to the owner terminal210 by the web server F11 and the vehicle managing unit F13. The vehiclemanaging unit F13 registers the input information in the vehicleregistration table.

Each row in the table illustrated in FIG. 4 represents one record of thevehicle registration table (the same is true of tables illustrated inFIGS. 5 to 11). Each record of the vehicle registration table includesfields of vehicle ID, registration number, owner ID, parking lotaddress, parking lot position, vehicle manufacturer, popular name,color, year of registration, movement limiting conditions, and onboardcommunication device address. The vehicle ID is information for uniquelyidentifying a vehicle. The vehicle ID is information which is set, forexample, by the vehicle managing unit F13. “Unique” means that eachvehicle can be identified exclusively in the information system. In thefollowing description, “unique” has the same meaning. The registrationnumber is an automobile registration number of a vehicle and includes acharacter string indicating a branch office of the transportationbureau/office for motor vehicle inspection and registration, a characterstring indicating a model of the vehicle, a character indicating whetherthe vehicle is an owner-driven car, and a type designation number.

The owner ID is information for uniquely identifying an owner of avehicle which is registered in the carsharing service using theinformation system according to this embodiment. For example, the ownerID may be the same information as information which was registered inthe central server 400 when the owner purchased the vehicle. The parkinglot address is, for example, an address indicating a housing location ofthe vehicle described in a garage certificate. The parking lot positionis information indicating the parking lot address, for example, using alatitude and longitude. The vehicle manufacturer is informationindicating a manufacturer having manufactured the vehicle. The popularname is a nickname of the vehicle and is a product name which is givento the vehicle sold by the vehicle manufacturer. The popular name may bementioned as a “vehicle model.” The color is a color of the vehicle.When the vehicle is painted in two or more colors, a predeterminednumber of colors may be disposed from the color having the largestsurface area as the color. The year of registration is a year ofregistration of the vehicle shown in a vehicle inspection certificate.

The movement limiting conditions represent conditions for vehiclemovement limiting which are agreed by the owner of the vehicle. Forexample, a movement limiting condition may be that a movement range islimited to a specific region (in the C2-shi). The movement limitingcondition may include designation of a date and time. For example, amovement limiting condition is that the vehicle may be fixed to aparking lot of the home on weekdays. For example, a movement limitingcondition is that the vehicle may be fixed to the parking lot of thehome from 21:00 every day to 7:00 on the next day. The movement limitingconditions may be temporary. For example, a movement limiting conditionmay be that the vehicle is fixed to a specific geographical position ona specific date and time. The onboard communication device address is anaddress on a public network of an onboard communication device which isincorporated into the onboard device 10A and which can communicatewirelessly. For example, the address may be a phone number on a mobilephone network. For example, the onboard communication device may be acommunication device which can access a base station of a mobile phonenetwork. The onboard device 10A can access a public network (forexample, the Internet) via the mobile phone network using the onboardcommunication device.

FIG. 5 is a diagram illustrating a configuration of the clusterdefinition table in the vehicle DB D12. The cluster definition table isa table in which cluster requirements for grouping a plurality ofvehicles into clusters are defined. The cluster definition table may beprepared by the vehicle managing unit F13 in response to a settingoperation from a manager of the information system.

A cluster is formed based on at least one of geographical positions suchas locations of parking lots at which vehicles are parked, movementranges of the vehicles, activity ranges of owners of the vehicles, andfriendship ranges of the owners. For example, the movement range of avehicle may be set by causing an owner thereof to set a movement rangeof the vehicle at the time of registration of the vehicle. The movementrange of a vehicle can be designated by a maximum distance from theposition of the parking lot address or the like. The movement range maybe designated as a polygonal area with a vertex array of latitude andlongitude. The activity range of an owner of a vehicle can beexemplified as a living range of the owner of the vehicle, the vicinityof an address of a place of work, or the like. A cluster which is formedbased on locations of parking lots or movement ranges of vehicles is anexample of a group of vehicles which are formed based on thegeographical position relationship correlated with the vehicles.

The activity range of an owner of a vehicle can be designated by anaddress, a maximum distance from the address, and the like. A clusterwhich is formed based on the activity range of an owner of a vehicle isan example of a group of vehicles which is formed based on thegeographical position relationship correlated with the vehicles. Thefriendship range of an owner refers to, for example, a range of personsassociated with the owner and can be specified, for example, by a name,an address, and a friendship in SNS. Since the friendship range of anowner is associated with addresses of owners and friends and the like, acluster which his formed based on the friendship range of an owner is anexample of a group of vehicles which are formed based on thegeographical position relationship correlated with the vehicles.

Each record in the cluster definition table includes a cluster ID, acluster address, and a cluster position range. The cluster ID isinformation for uniquely identifying a cluster. The cluster address isan address part which is commonly included in parking lot addresses ofvehicles included in the cluster. For example, when a cluster address isC2-shi, P1-ken, the parking lot addresses of vehicles included in thecorresponding cluster include “C2-shi, P1-ken” and it can be understoodthat vehicles of the region are grouped. The cluster position rangedefines a range of the parking lot addresses of vehicles included in thecorresponding cluster using a polygon including latitude and longitude.For example, a rectangular cluster position range can include latitudeand longitude of an upper-left vertex (X1, Y1) and a lower-right vertex(X2, Y2) of the range of the parking lot addresses of the vehiclesincluded in the cluster.

FIG. 6 is a diagram illustrating a configuration of the cluster membertable in the vehicle DB D12. The cluster member table is a table forclassifying vehicles which are supplied for the carsharing serviceprovided by the information system into clusters. In this embodiment, avehicle belongs to at least one cluster. Each record of the clustermember table includes a cluster ID, the number of registered vehicles,and an array of vehicle IDs. The cluster ID is the same ID as defined inthe cluster definition table and description thereof will not berepeated. The number of registered vehicles is the number of vehiclesbelonging to the corresponding cluster. The array of vehicle IDs is anarray of vehicle IDs of the vehicles belonging to the correspondingcluster. In the cluster member table, the maximum value of the number ofregistered vehicles may be limited. The cluster member table is anexample of a group storage unit.

FIG. 7 is a diagram illustrating a configuration of the ownerregistration table in the owner DB D11. The owner registration tabledefines owners of vehicles which are supplied for the carsharing serviceprovided by the information system. The owner registration tableincludes an owner ID, a name, an address, and a password. The owner IDis information for uniquely identifying an owner in the informationsystem. As described above, the owner ID may be common to that which anowner of a vehicle registers in the central server 400 at the time ofpurchase of the vehicle. The name is a name of an owner. The address isan address at which the owner lives.

The owner ID and the password are given to the owner by the centralserver 400 when an owner of a vehicle purchases the vehicle. That is,the owner ID and the password are managed along with deviceauthentication information of the key unit 100 and terminalauthentication information by the central server 400. An owner can besubjected to reissuance of terminal authentication informationcorresponding to device authentication information of the key unit 100mounted in the vehicle 10 by causing the central server 400 toauthenticate the owner with the owner ID and the password.

FIG. 8 is a diagram illustrating a configuration of the owner evaluationtable in the owner DB D11. The owner evaluation table includes an ownerID, provision of a movement schedule, agreement to movement limiting, amonthly frequency of vehicle interior rental change due to change of aschedule, a monthly frequency of vehicle interior rental implementation,and a monthly sum of incentive points. Here, the owner ID is the same asillustrated in FIGS. 6 and 7. The provision of a movement schedule isinformation indicating whether an owner identified by the owner IDagrees to provision of a movement schedule. When the owner supplies aplurality of vehicles for the carsharing service, the provision of amovement schedule may be set for each vehicle. Points may be added witha unit point of 1 in a case in which movement schedules of a pluralityof vehicles are provided, and the added points may be set in the tableillustrated in FIG. 8.

The monthly frequency of vehicle interior rental change due to change ofa schedule represents a monthly frequency in which a movement scheduleof a vehicle is changed by an owner's circumstances and a reservationfor rental of the interior of a vehicle is changed to another vehicle.The monthly frequency of vehicle interior rental implementationrepresents a monthly frequency in which a reservation for rental of theinterior of a vehicle is implemented without changing the movementschedule of the vehicle (or regardless of whether the movement schedulehas changed). The monthly sum of incentive points represents a monthlysum of incentive points which are offered to the owner and which iscalculated based on the provision of a movement schedule, the monthlyfrequency of vehicle interior rental change due to change of a schedule,and the monthly frequency of vehicle interior rental implementation. Inthis embodiment, the owner evaluation table evaluates owners for eachmonth, but the evaluation of owners is not limited to a month and theinformation system can evaluate owners in various evaluation periodssuch as a week, a season, and a year.

FIG. 9 is a diagram illustrating a configuration of the userregistration table in the user DB D13. The user registration tabledefines owners who receive the carsharing service provided by theinformation system. The user registration table includes a user ID, aname, an address, and password. The user ID is information for uniquelyidentifying a user in the information system. The name is a name of auser. The address is an address at which a user lives. The password is apassword which a user applies for the user ID and which is accepted bythe information system.

When authentication of a user using the corresponding user ID and thecorresponding password has succeeded, the rental managing unit F15 ofthe rental management server 410 transmits a request for issuance ofterminal authentication information for using a vehicle which will beused by a user to the central server 400. The request for issuanceincludes an owner ID and a password of the vehicle which is rented tothe user. The central server 400 authenticates the request for issuanceusing the owner ID and the password of the vehicle in response to therequest for issuance of terminal authentication information from therental management server 410. When the authentication has succeeded, thecentral server 400 manages temporary issuance of terminal authenticationinformation which is authenticated by the key unit 100 correlated withthe vehicle ID of the owner ID and the vehicle, that is, issuance of aone-time key. That is, the central server 400 issues a one-time key forthe user terminal 200 in response to the request for issuance ofterminal authentication information from the rental managing unit F15.

FIG. 10 is a diagram illustrating a configuration of movement scheduleinformation in the movement schedule DB D14. The movement scheduleinformation records a movement schedule for each vehicle. Each record ofthe movement schedule includes, for example, a date, a time, and avehicle movement schedule. The configuration of the movement scheduleinformation is not limited to that illustrated in FIG. 10, and themovement schedule may be defined as a fixed range at predetermined timeintervals (for example, intervals of one hour, four hours, forenoon,afternoon, or day).

FIG. 11 is a diagram illustrating a configuration of vehicle interiorrental schedule information in the rental schedule DB D15. The vehicleinterior rental schedule information records a vehicle interior rentalschedule for each vehicle. Each record of the vehicle interior rentalschedule information includes, for example, a date, a time, and a rentalschedule. The configuration of the vehicle interior rental scheduleinformation is not limited to that illustrated in FIG. 11, and a vehicleinterior rental schedule may be defined as a fixed range atpredetermined time intervals (for example, intervals of one hour, fourhours, forenoon, afternoon, or day). The vehicle interior rentalschedule information is an example of reserved schedule informationindicating a rental reservation situation of vehicles which are suppliedfor a vehicle rental service. Accordingly, the rental schedule DB D15functions as an example of a storage unit that stores reserved scheduleinformation.

<Process Flow>

FIG. 12 is a flowchart illustrating a process flow which is performed bythe reception unit F16 and the rental managing unit F15. In this processflow, the rental managing unit F15 publishes a list of carsharing targetvehicles on the web (S1). On the web, for example, information of thevehicle registration table illustrated in FIG. 4 can be published as alist. The rental managing unit F15 may omit information for identifyingan individual owner such as a registration number and an owner ID inpublication on the web. The rental managing unit F15 may omit detailedinformation which can specify a person such as a house number in theparking lot address in publication on the web.

Then, the reception unit F16 receives a vehicle interior rental requestfrom the user terminal 200 (S2). The vehicle interior rental requestincludes information of the user terminal 200 for specifying the userterminal 200 such as an address on the network N1 including a mobilephone network which is an address that is used for the rental managingunit F15 to return a response to the user terminal 200. The informationof the user terminal 200 is an example of receiver terminal information.When the reception unit F16 receives the vehicle interior rentalrequest, the rental managing unit F15 confirms a user ID and a password(S3). When confirmation of the user ID and the password has succeeded,the reception unit F16 receives an input of a vehicle interior rentalapplication (S4A). In the vehicle interior rental application, a regionin which a user desires rental of the interior of a vehicle, an address,date and time information, and the like are designated. The rentalmanaging unit F15 specifies a suitable vehicle with reference toposition information of vehicles (S4B). That is, the rental managingunit F15 searches records of vehicle IDs in which a parking lot addressis included the region in which the user desires rental of the interiorof a vehicle in the vehicle registration table of the vehicle DB D12.Alternatively, the rental managing unit F15 may search records ofvehicle IDs in which a parking lot position (latitude and longitude) isincluded in the region in which rental of the interior of a vehicle isdesired in the vehicle registration table of the vehicle DB D12 in S4A.The rental managing unit F15 may scan the records included in thevehicle registration table and may inquire of the onboard device 10A ofthe vehicle specified with the address or the parking lot position(latitude and longitude) about a current location via the onboardcommunication device. For example, the onboard device 10A of the vehicleacquires the current location from GPS signals and returns a response tothe rental managing unit F15 via the onboard communication device.Accordingly, the rental managing unit F15 may narrow the vehicles basedon the current location of the vehicle along with the parking lotaddress or the parking lot position (latitude and longitude) in thevehicle registration table. Then, the rental managing unit F15determines whether there is a suitable vehicle in a region desired bythe user (S4C). When there is not suitable vehicle, the rental managingunit F15 performs the process flow of S7. As exemplified in S4A, a userequest includes information for specifying geographical conditions inwhich the vehicle rental service is received. The process of S4B is anexample of referring to position information of vehicles which aresupplied for the vehicle rental service.

When there is a suitable vehicle, the rental managing unit F15 performsa vehicle schedule searching process (S5). In this process, the rentalmanaging unit F15 searches for a vehicle of which the interior can beused at the date and time desired by the user in the region desired bythe user (referred to as a schedule-suitable vehicle). When there is avehicle suitable for the vehicle interior rental application as theresult of the vehicle schedule searching process (YES in S6), the rentalmanaging unit F15 presents the schedule-suitable vehicle to the userterminal 200. The rental managing unit F15 performs the processes of S5and S6 as an example of determining that a reservation for rental of theinterior of a vehicle at a scheduled date and time at which the vehiclewill not be used. When there is a plurality of schedule-suitablevehicles, the rental managing unit F15 presents a list ofschedule-suitable vehicles in a recommended order to the user terminal200 (S8). The processes of S4B, S4C, and S8 are an example of providinginformation on the vehicle satisfying the geographical conditions.

For example, the rental managing unit F15 may set the order of gettingapart from the address designated by the vehicle interior rentalapplication (the input in S4A) as the recommended order ofschedule-suitable vehicles. By setting the order of getting apart fromthe address, convenience for the user is improved. The rental managingunit F15 may set the recommended order of schedule-suitable vehicles togive priority to a vehicle of an owner having agreed to provision of themovement schedule. The rental managing unit F15 may sort vehicles in theorder of owners from the highest number of incentive points in the ownerevaluation table (see FIG. 8) and set the sorted order as therecommended order of schedule-suitable vehicles. The rental managingunit F15 may weight and combine these conditions, add the weight when aplurality of conditions are satisfied, and set the order of addedweights from the highest weighted as the recommended order. This isbecause it is possible to more surely predict implementation of rentalof a vehicle of an owner having agreed to provision of the movementschedule or a vehicle of an owner having a high number of incentivepoints in comparison with vehicles of owners not having agreed orvehicles of owners having low incentive points. The process of S8 is anexample of a process of providing information on vehicles in arecommended order in which a vehicle of which provision of movementschedule information is permitted or a vehicle of an owner having a highnumber of incentive points has priority when there is a plurality ofvehicles which satisfy the desired rental schedule.

Then, the rental managing unit F15 receives confirmation of a user viathe user terminal 200. When there is a plurality of schedule-suitablevehicle s, the rental managing unit F15 promotes the user to select avehicle via the user terminal 200 and receives the selection (S9). Then,the rental managing unit F15 sets a reservation for rental of theinterior of the corresponding vehicle in the rental schedule DB D15after confirmation and selection by the user (S10). Accordingly, whenthere is a vehicle suitable for the desired vehicle interior rentaldate, a reservation for rental of the interior of the vehicle is set inthe rental schedule DB D15 and a user can use the interior of thevehicle in accordance with the reservation. On the other hand, whenthere is no vehicle suitable for the vehicle interior rental applicationas the result of the vehicle schedule searching process (NO in S4C orS6), the rental managing unit F15 returns a response indicating thatthere is no schedule-suitable vehicle to the user terminal 200 (S7).

FIG. 13 is a flowchart illustrating details of the vehicle schedulesearching process (S5 in FIG. 12). In this process, the rental managingunit F15 sequentially selects available vehicles (which are specified inS4B) in the region input with the vehicle interior rental application(S4A) and sequentially checks the movement schedule of the selectedvehicle (SM). Then, when the vehicle is scheduled to be driven at thedesired use date and time (YES in S52), the rental managing unit F15determines whether all the available vehicles in the region input withthe vehicle interior rental application have been checked. When all thevehicles have not been yet checked (NO in S53), the rental managing unitF15 returns the process flow to SM. On the other hand, when all thevehicles have been checked (YES in S53), the rental managing unit F15ends the process flow.

On the other hand, when the vehicle is not scheduled to be driven at thedesired use date and time (NO in S52), the rental managing unit F15checks the interior rental schedule of the vehicle (S54). When there isa previous engagement for the vehicle (YES in S55), the rental managingunit F15 determines whether all the available vehicles in the regionhave been checked (S56). When all the vehicles have not been yet checked(NO in S56), the rental managing unit F15 returns the process flow toS51. On the other hand, when all the vehicles have been checked (YES inS56), the rental managing unit F15 ends the process flow.

When it is determined in S55 that there is no previous engagement forthe vehicle (NO in S55), the rental managing unit F15 performs aschedule-suitable vehicle acknowledging process (S57). Theschedule-suitable vehicle acknowledging process is, for example, aprocess of adding vehicle IDs of schedule-suitable vehicles to a listfor work. Then, the rental managing unit F15 determines whether all thevehicles have been checked (S58). When all the vehicles have not beenyet checked (NO in S58), the rental managing unit F15 returns theprocess flow to S51. On the other hand, when all the vehicles have beenchecked (YES in S58), the rental managing unit F15 ends the processflow. When the process flow ends, the rental managing unit F15 canperform the determination of S6 in FIG. 12 based on the number ofsuitable vehicles in a work list.

FIG. 14 is a flowchart illustrating the vehicle registration receivingprocess which is performed by the vehicle managing unit F13. In thevehicle registration receiving process, the vehicle managing unit F13first receives information of an interior-rental vehicle from the ownerterminal 210 (S110). Then, the vehicle managing unit F13 registers thereceived information in the vehicle registration table in the vehicle DBD12 (S111).

Then, the vehicle managing unit F13 promotes the owner terminal 210 toinput information and checks whether movement schedule information is tobe provided (S112). When the movement schedule information of thevehicle is to be provided, the vehicle managing unit F13 registers anintention of the owner of the vehicle to provide the movement scheduleinformation in the owner registration table and adds incentive points tothe monthly incentive points of the owner (S113). The addition method isnot particularly limited and, for example, predetermined points may beadded when the intention to provide the movement schedule information isdisplayed. For example, when the intention to provide the movementschedule information is maintained, for example, predetermined pointsmay be added for the owner for each month. The process of S113 is anexample of a process of an incentive offering unit that offers apredetermined incentive to the owner of the vehicle of which provisionof the movement schedule information is permitted.

Then, the vehicle managing unit F13 checks whether the owner agrees tomovement liming via the owner terminal 210 (S114). The movement limitingmeans that a movement range of a vehicle to be registered is limited toa specific region. When the owner agrees to the movement limiting, thevehicle managing unit F13 promotes the owner terminal 210 to inputinformation, receives an input of movement limiting conditions, andregisters the movement limiting conditions. An example of the movementlimiting conditions is a condition that a moving region of a vehicle islimited to a predetermined area. The movement limiting conditions mayinclude designation of a time period and designation of days. An examplethereof is a condition that the vehicle does not move from a homeparking lot on weekdays. When the owner agrees to the movement limiting,the vehicle managing unit F13 sets the movement limiting conditions inthe vehicle registration table and adds points to the monthly incentivepoints of the owner (S115). The addition method is not particularlylimited and, for example, predetermined points may be added when themovement limiting is registered. For example, when the movement limitingis maintained, predetermined points may be added for the ownerperiodically, for example, every month. The process of S115 is anexample of a process of offering a predetermined incentive to the ownerhaving agreed to the movement limiting of the vehicle.

FIG. 15 is a flowchart illustrating a vehicle renting process which isperformed by the rental managing unit F15. This process is performed atpredetermined intervals (for example, at predetermined time intervals).In this process, the rental managing unit F15 checks the vehicleinterior rental schedule (S100). It is determined whether there is arental schedule which is within a predetermined time (S101). When therental schedule is within the predetermined time, the rental managingunit F15 transmits information for identifying a reserved vehicle andterminal authentication information corresponding to deviceauthentication information in the key unit 100 mounted in the reservedvehicle to the user terminal 200 of the user (S102). Then, the rentalmanaging unit F15 updates a monthly frequency of vehicle interior rentalimplementation and incentive points of the owner of the vehicle (S103).The monthly frequency of vehicle interior rental implementation is anexample of a rate at which rental of the interior of a vehicle accordingto the reservation schedule information can be implemented. Accordingly,the rental managing unit F15 can determine the incentive points whichare offered to the owner of the reserved vehicle based on the rate atwhich rental of the interior of a vehicle of which rental of theinterior has been reserved according to the reservation scheduleinformation could be implemented in the process of S103.

The user terminal 200 receives terminal authentication information whichis temporarily available, perform authentication with the key unit 100,and can temporarily unlock the interior of the vehicle. Examples ofinformation for identifying a vehicle include a registration number,parking lot address, a parking lot position, a vehicle manufacturer, apopular name, and a color. A user finds out the correspondinginformation from the information for identifying a vehicle, performsauthentication between the user terminal 200 and the key unit 100, andcan temporarily use the interior of the vehicle.

<Advantages of First Embodiment>

As described above, with the information system according to the firstembodiment, it is determined whether there is a vehicle suitable for avehicle interior rental request from a user who desires rental of theinterior of a vehicle from vehicles which are supplied for thecarsharing service in consideration of movement schedules of vehicles.Accordingly, it is possible to satisfactorily determine a vehicleinterior rental schedule in comparison with a case in which it isdetermined whether there is a vehicle suitable for the vehicle interiorrental request based on only the vehicle rental schedule information. Itis also possible to curb occurrence of an event in which implementationof rental of the interior of a vehicle is hindered due to the movementschedule of an owner of a vehicle. Accordingly, for example, when theinterior of a vehicle is designated as a delivery (or pickup)destination of home delivery, it is possible to decrease a likelihoodthat a scheduled receiver (or a pickup user) of baggage will not be ableto receive baggage of the interior of the vehicle due to movement of thevehicle.

In the information system according to the first embodiment, theschedule information acquiring unit F14 can extract a movement scheduleof a vehicle from an activity schedule of an owner of the vehicle andset the movement schedule. Accordingly, by setting an activity scheduleincluding “drive,” “transportation,” “automatic driving,” “autonomousdriving command,” and “unmanned driving” in an activity schedulemanagement tool which is generally used, an owner of a vehicle canprovide determination materials for determination of whether the vehicleof the owner is to be used in the vehicle schedule searching processwhich is performed by the rental managing unit F15 without performing asetting operation on the movement schedule DB D15. Accordingly, avehicle owner can reduce occurrence of new labor for supplying a vehicleto a carsharing service and can provide a movement schedule of thevehicle to the rental managing unit F15.

In the process flow illustrated in FIG. 15, when there is a rentalschedule in which the rental date and time is within a predeterminedtime, the rental managing unit F15 confirms the vehicle interior rentalschedule at predetermined intervals and transmits information foridentifying a reserved vehicle and terminal authentication informationcorresponding to device authentication information in the key unit 100of the reserved vehicle to the corresponding user. However, instead ofthis process, the rental managing unit F15 may receive a request fortransmission of terminal authentication information which can be usedfor authentication in the key unit 100 and transmit the terminalauthentication information which can be used for authentication in thekey unit 100 to the requesting user when the rental schedule is within apredetermined time.

In the first embodiment, when an owner of a vehicle agrees to provisionof a movement schedule of the vehicle, incentive points are offered tothe owner. Accordingly, the information system can promote an owner of avehicle to provide a movement schedule of the vehicle and provide astable carsharing service. In the first embodiment, when an owner of avehicle maintains an intention to provide a movement schedule of thevehicle, incentive points may be offered to the owner for each month.Through this service, an owner of a vehicle can maintain an intention toprovide a movement schedule of the vehicle and the carsharing system 1according to the first embodiment can accurately collect movementschedules.

According to the first embodiment, when a plurality of schedule-suitablevehicles has been detected, the rental managing unit F15 prepares a listof vehicles in the recommended order in which a vehicle closer to adesired address of a user, a vehicle of which a movement schedule isprovided, a vehicle of which an owner has a high incentive point, or thelike has priority and presents the list to a user. The rental managingunit F15 can enhance convenience for a user in the vehicle interiorrental service. That is, by providing a vehicle closest to a desiredaddress of a user, convenience for the user is improved. By givingpriority a vehicle of which a movement schedule is provided, a vehicleof which an owner has a high incentive point, or the like, it ispossible to preferentially recommend a vehicle of a reliable owner or anowner having many actual results and to enhance a likelihood that thevehicle interior rental service will be provided.

According to the first embodiment, when an owner of a vehicle agrees tomovement limiting of the vehicle, incentive points are offered to theowner. When a vehicle is subjected to the movement limiting, a user canmore satisfactorily use the interior of a vehicle in the carsharingservice. In the first embodiment, when the movement limiting of avehicle is maintained, incentive points may be offered to the owner foreach month. Through this service, an owner of a vehicle can maintain anintention to limit movement of the vehicle and a user can moresatisfactorily use the interior of the vehicle.

According to the first embodiment, when the interior of a vehicle isreserved by another user and the interior of the vehicle is used asscheduled, the incentive points of the corresponding owner areincreased. Accordingly, in the carsharing service using the informationsystem, an owner of a vehicle can be expected to behave such that theinterior of the vehicle is used as scheduled as much as possible. Forexample, an owner of a vehicle takes consideration such that rental ofthe interior of the vehicle in the carsharing service is not affected bychange of the owner's activity schedule and it is thus possible toprovide a stable carsharing service.

Second Embodiment

An information system according to a second embodiment will be describedbelow with reference to FIGS. 16A to 18. In the first embodiment, acarsharing service in which a reservation for rental of the interior ofa vehicle is carried out for a user in consideration of a movementschedule of an owner of a vehicle and the rental is carried out has beendescribed above. In the second embodiment, a processing example in whichthe interior of a vehicle which is rented in the first embodiment isused as a delivery destination of home delivery or online shopping willbe described. Accordingly, in the second embodiment, a user terminal 200is described as a deliverer terminal 220 of a home delivery company anda receiver terminal 230 which receives baggage. In the informationsystem according to the second embodiment, a configuration other than aconfiguration associated with processes using the interior of a vehicleas a delivery destination of home delivery or online shopping is thesame as in the first embodiment. Therefore, the same elements in thesecond embodiment as in the first embodiment will be referred to by thesame reference signs and description thereof will not be repeated. Atleast the configurations illustrated in FIGS. 1 and 2 are also appliedto the second embodiment. At least the processes of the rental managingunit F15 illustrated in FIGS. 12 to 14 and the vehicle registeringprocess of the vehicle managing unit F13 are also performed in thesecond embodiment.

FIGS. 16A and 16B are sequence charts of the information systemaccording to the second embodiment. FIGS. 16A and 16B illustratereception and transmission of information between an onboard device 10Amounted in a vehicle 10, a receiver terminal 230 of a receiver whoreceives home delivery, a deliverer terminal 220 of a home deliverycompany, a rental management server 410, and a central server 400. Here,the receiver is a receiver serving as a delivery destination of homedelivery and is designated as a delivery destination, for example, bynotification of a home delivery schedule from the home delivery company.The receiver may be a purchaser of a product in online shopping or thelike.

The rental management server 410 is a server that manages a rentalschedule or the like in a carsharing service, similarly to the firstembodiment. In the following embodiment, it is assumed that the rentalmanagement server 410 is unified with a server of a home deliveryservice provider or an online shopping service provider. Here, abusiness server that manages a home delivery service provider or anonline shopping service provider may be provided separately from therental management server 410 that manages a rental schedule or the likein the carsharing service. That is, a business server that supportsvarious businesses and the rental management server 410 and the centralserver 400 can receive and transmit information via a network N1 andprovide a service in cooperation. On the other hand, the businessserver, the rental management server 410, and the central server 400 maybe unified as a single body.

In a process flow of the information system, for example, the receiverterminal 230 sets a delivery request including a communication addressof the receiver terminal 230 on the network N1, a delivery destinationof a purchased product, and a scheduled (desired) delivery date and timein an online shopping service in the rental management server 410. Thereceiver terminal 230 may confirm a delivery destination address and ascheduled (desired) date and time of a delivery object from thecommunication address of the receiver terminal 230 on the network N1,for example, in response to notification of delivery date and timeconfirmation from a home delivery company and set the confirmationresult in the rental management server 410 (T11). That is, in the secondembodiment, a scheduled delivery date and time at which delivery ofbaggage is performed is described as an example of a desired rentalschedule in which a vehicle is used. The scheduled delivery date andtime is an example of a scheduled transportation date and time.

Then, the rental management server 410 receives an input from thereceiver terminal 230 and registers the delivery destination (T12). Forexample, when the interior of a vehicle located near a deliverydestination address of a product purchased in online shopping isdesignated as a delivery destination of online shopping by the receiverterminal 230, the rental management server 410 searches for availableschedules of vehicles which are supplied for the carsharing service inthe same order as in the rental managing unit F15 described in the firstembodiment, and presents available vehicles to the receiver terminal230.

When the business server that manages an online shopping service and therental management server 410 are separate from each other, the businessserver can request the rental management server 410 to search foravailable schedules of vehicles and acquire the search result from therental management server 410. By causing a receiver to select one in alist of vehicles acquired as the search result using the receiverterminal 230, a vehicle which is available at the scheduled deliverydate and time of online shopping is selected and is registered as adelivery destination, for example, in the business server of a homedelivery company. That is, the rental management server 410 can be saidto select a vehicle which is available at a scheduled transportationdate and time and to set a reservation for use of the selected vehicleat the scheduled delivery date and time in the reservation scheduleinformation.

In the process of T12, as described above, when the receiver terminal230 has been notified of a request for confirmation of a delivery dateand time from the home delivery company using an electronic mail or thelike, a request for change of the delivery destination to the interiorof a vehicle located around the delivery destination address may beinput from the receiver terminal 230. When the delivery destination ischanged to the interior of a vehicle, the rental management server 410searches for available schedules of vehicles which are supplied for thecarsharing service in the same sequence as performed by the rentalmanaging unit F15 which is described in the first embodiment andpresents available vehicles to the receiver terminal 230. When thebusiness server that manages the home delivery service and the rentalmanagement server 410 are separate from each other, the business servercan request the rental management server 410 to search for availableschedules of vehicles and acquire the search result from the rentalmanagement server 410. By causing the receiver to select vehicles in thelist of vehicles acquired as the search result using the receiverterminal 230, vehicles which are available at the scheduled deliverydate and time are selected and registered as a delivery destination inthe business server of the home delivery company.

When the interior of a vehicle is registered as a delivery destination,the rental management server 410 notifies the deliverer terminal 220 ofinformation indicating the delivery destination (T13). Accordingly, therental management server 410 can control transmission of information foridentifying the selected vehicle to a terminal of a service userassociated with transportation of baggage. When the business server thatmanages the home delivery service and the rental management server 410are separate from each other, the rental management server 410 cannotify the deliverer terminal 220 of information on the deliverydestination via the business server for a home delivery service. Theinformation indicating a delivery destination includes identificationinformation for specifying a delivery object, an address and a name of areceiver, and information for specifying the delivery object.

When the scheduled delivery date and time is within a predetermined time(for example, within one day), the deliverer terminal 220 requests therental management server 410 to transmit terminal authenticationinformation for unlocking a gate or door to the interior of a vehicle atthe time of delivery (T14). When the terminal authentication informationis requested from the deliverer terminal 220, the rental managementserver 410 designates an owner ID, a vehicle ID, and a password of avehicle set as the delivery destination and requests the central server400 to transmit the terminal authentication information (T15). Similarlyto the first embodiment, the terminal authentication information isinformation which corresponds to device authentication informationstored in the key unit 100 and is used for authentication in the keyunit 100.

Then, the central server 400 issues terminal authentication informationwhich is used for authentication in the key unit 100 and which isregistered in correlation with the designated owner ID and vehicle ID(T16). The deliverer terminal 220 receives the terminal authenticationinformation which is a one-time key via the rental management server 410or directly from the central server 400 (T17). Accordingly, the rentalmanagement server 410 can control transmission of access permissioninformation for permitting an access to the interior of the selectedvehicle. Transmission of the terminal authentication information may beperformed by causing the deliverer terminal 220 to request the rentalmanagement server 410 or the central server 400 to transmit the terminalauthentication information, for example, when a deliverer arrives as aparking position of the vehicle as the delivery destination.Transmission of the terminal authentication information may beperformed, for example, at the same time as notification of informationindicating the delivery destination in T13. That is, informationindicating a delivery destination and terminal authenticationinformation used for authentication in the key unit 100 of the deliverydestination may be transmitted to the deliverer terminal 220 atdifferent times or may be transmitted to the deliverer terminal at thesame time.

The deliverer moves to the parking lot address and the parking lotposition of the vehicle designated as the delivery destination using acar navigation function or the like and specifies a vehicle based on aregistration number, a vehicle manufacturer, a popular name (a vehiclemodel) of the vehicle, a color, or the like. Then, the delivererterminal 220 requests the key unit 100 mounted in the vehicle 10designated as the delivery destination for authentication based on thereceived terminal authentication information in response to thedeliverer's operation and performs an unlocking operation (T18). Then,the key unit 100 of the onboard device 10A performs the requestedauthentication and unlocks a gate or door to the interior of the vehicle10 in accordance with an unlocking request when the authentication hassucceeded (T19).

When the gate or door to the interior of the vehicle 10 is unlocked, thedeliverer opens the gate or door to the interior of the vehicle. When adelivery object can be received in the interior of the vehicle after thegate or door to the interior of the vehicle has been opened, thedeliverer completes the delivery. The deliverer terminal 220 transmitsdelivery completion notification to the rental management server 410 inresponse to the deliver's operation (T23). However, when a volume orsize of the delivery object exceeds the allowable capacity of theinterior of the vehicle (YES in T20), an alternative vehicle isnecessary. An example of such a case is a case in which a plurality ofpieces of baggage is already stored in the interior of the vehicle andthe residual capacity of the interior of the vehicle is less than thevolume of the delivery object. Therefore, when the capacity of theinterior of the vehicle is insufficient and thus an alternative vehicleis necessary, the deliverer terminal 220 requests the rental managementserver 410 for an alternative vehicle in response to the deliverer'soperation (T21). The rental management server 410 searches for anotheralternative vehicle (T22). When another alternative vehicle is searchedfor, the rental management server 410 returns the process flow to T15and request transmission of terminal authentication information used forauthentication of the alternative vehicle.

Although not illustrated in FIGS. 16A and 16B, the rental managementserver 410 transmits the notification thereof to the deliverer terminal220 and ends the process flow when another alternative vehicle has notbeen searched for in the process of T22. When the notificationindicating that another alternative vehicle has not been searched for isreceived from the rental management server 410, the deliverer terminal220 presents the notification to the deliverer using a display or thelike. Then, the deliverer gives up completion of the delivery into theinterior of a vehicle on that day and returns with the delivery object.

When the deliverer terminal 220 transmits the delivery completionnotification to the rental management server 410 in T23, the delivererterminal 220 invalidates the terminal authentication information, forexample, by deleting the terminal authentication information stored inthe deliverer terminal 220 (T24). After the delivery completionnotification has been received, the rental management server 410requests the central server 400 to issue terminal authenticationinformation as a one-time key for a receiver when the receiver ofbaggage is not an owner of the vehicle (T25). When the central server400 issues the terminal authentication information (T26), the rentalmanagement server 410 transmits a delivery completion notification alongwith the terminal authentication information issued from the centralserver to the receiver terminal 230 (T27).

Regarding issuance of the terminal authentication information, forexample, the rental management server 410 may issue the terminalauthentication information to a receiver of the baggage at the time atwhich the rental management server 410 registers the interior of avehicle as a delivery destination and transmits information indicatingthe delivery destination to the deliverer terminal 220 in the process ofT13, that is, at the time at which the interior of the vehicle isreserved. The time at which the interior of the vehicle is reserved is,for example, a time at which a reservation for rental of the interior ofthe vehicle is registered in FIG. 12 according to the first embodiment(at the time of performing S10). Accordingly, the rental managementserver 410 as a managing unit can be said to perform a process of givinga permission for locking and unlocking to a scheduled rental user usingelectronic information at the scheduled use date and time withsettlement of a use reservation through processes of T13 and T26. Thereceiver of baggage is an example of the scheduled rental user andissuance of terminal authentication information for the receiver ofbaggage is an example of the permission for locking and unlocking.

A number on a mobile phone network or an address on the network as anaddress of the receiver terminal 230 is an example of an address of theterminal. The delivery completion notification includes information foridentifying a vehicle as a delivery destination. When the receiver ofbaggage is an owner of a vehicle, terminal authentication informationwithout a validity term has been transmitted to the owner terminal 210and thus the processes of T25 and T26 are skipped. Accordingly, theprocesses of T25 to T27 include determination of that the terminalauthentication information has been transmitted and is an example of aprocess in which the rental management server 410 controls transmissionof information for identifying the selected vehicle and accesspermission information for permitting an access to the interior of theselected vehicle to the terminal of the receiver.

When the terminal authentication information is received (T28), thereceiver terminal 230 requests authentication in the key unit 100mounted in the vehicle 10 which is designated as a delivery destinationusing the received terminal authentication information and performs anunlocking operation (T29). When the receiver is an owner of the vehicle,the authentication can be performed using terminal authenticationinformation stored in the owner terminal 210 without a validity term.Then, the key unit 100 of the onboard device 10A performs theauthentication and unlocks the gate or door to the interior of thevehicle 10 in response to an unlocking request when the authenticationhas succeeded (T30).

Then, when the receiver acquires baggage from the interior of thevehicle and close the gate or door to the interior of the vehicle, thekey unit 100 of the onboard device 10A transmits an instruction toinvalidate the terminal authentication information to the receiverterminal 230 (T31), and the receiver terminal 230 invalidates theterminal authentication information by deleting an electronic key or thelike (T32). The receiver terminal 230 may promote the receiver toconfirm whether baggage has been acquired, and invalidate the terminalauthentication information when an input indicating that the receiverhas received baggage has been received. When the receiver is an owner ofthe vehicle, the process of invalidating the terminal authenticationinformation stored without a validity term in the owner terminal 210 isnot performed.

The receiver terminal 230 transmits a reception notification to therental management server 410 (T33), and the rental management server 410notifies the central server 400 that the electronic key issued to thereceiver terminal 230 has been invalidated (T34). Then, the rentalmanagement server 410 updates the incentive points of the owner of thevehicle. T35 is an example of a process of determining the incentivepoints offered to the owner of the reserved vehicle based on a rate ofvehicles of which the rental could be performed in accordance with thereservation schedule information to vehicles of which the rental isreserved in the reservation schedule information.

FIG. 17 is a flowchart illustrating a process flow of over-capacityprocessing which is performed by the reception unit F16 and the rentalmanaging unit F15 of the rental management server 410. In this processflow, the rental management server 410 receives a notificationindicating that the interior of the vehicle is over the capacity fromthe deliverer terminal 220 (S130). The notification indicating anover-capacity may designate a size, a capacity, or the like required foraccommodation of a delivery object.

Then, the rental management server 410 searches for an alternativevehicle from other vehicles belonging to the same cluster (S131). Forexample, capacities of the interiors of vehicles may be defined in thevehicle registration table (FIG. 4). The size of the interior of avehicle may be defined in a master database which is not illustrated foreach type of vehicle (such as a popular name or a model). When thenotification indicting an over-capacity includes a size, a capacity, orthe like required for accommodation of the delivery object and thecapacity of the interior of a vehicle can be acquired from the vehicleregistration table or the master database which is not illustrated, therental management server 410 can select a vehicle having an internalspace equal to or larger than the designated capacity. When the capacityof the internal space of a vehicle cannot be acquired, the rentalmanagement server 410 can simply search other vehicles belonging to thesame cluster as the vehicle having the over-capacity with reference tothe cluster member table. Accordingly, when the notification indicatingthat an over-capacity in which baggage to be transported cannot beaccommodated in the interior of the vehicle as the transportationdestination has occurred is received, the rental management server 410performs an example of a process of determining one vehicle of thevehicles belonging to the same group as the vehicle which is atransportation destination as an alternative vehicle through theprocesses of S130 and S131.

When an alternative vehicle has been searched for (YES in S132), therental management server 410 performs a process of changing a vehicleinterior rental schedule (S133). More specifically, the rentalmanagement server 410 reserves the interior of the alternative vehicleat the delivery date and time in the vehicle interior rental scheduleinformation and transmits information for identifying the alternativevehicle and terminal authentication information used for authenticationin the key unit 100 of the alternative vehicle as a one-time key to thedeliverer terminal 220 and the receiver terminal 230. Here, theinformation for identifying the alternative vehicle includes aregistration number, a parking lot address, a parking lot position, avehicle manufacturer, a popular name, and a color similarly to the firstembodiment. The terminal authentication information may be transmittedto the receiver terminal 230 after delivery has been completed.Accordingly, through the process of S133, the rental management server410 performs an example of a process of controlling transmission ofinformation for identifying the selected alternative vehicle and accesspermission information for permitting an access to the interior of thealternative vehicle to a terminal of a service user.

On the other hand, when an alternative vehicle has not been searched for(NO in S132), the rental management server 410 returns a responseindicating that there is no alternative vehicle to the delivererterminal 220 (S134). When the response indicating that there is noalternative vehicle is received by the deliverer terminal 220, thedeliverer gives up delivery to the interior of a vehicle on that dayand, for example, returns with the delivery object.

In FIGS. 16A, 16B, and 17, a process of causing the rental managementserver 410 to search for an alternative vehicle in response to a requestfor an alternative vehicle from the deliverer terminal 220 when thecapacity of a vehicle as a delivery destination is insufficient isillustrated. Another process example of requesting an alternativevehicle will be described now.

FIG. 18 is a flowchart illustrating a process flow which is performed bythe rental management server 410 having received a notification due tochange of a movement schedule from the owner terminal 210. This processflow is started when the rental management server 410 receives anotification indicating change of a movement schedule from the ownerterminal 210 (S120). In the notification indicating change of a movementschedule, for example, a date, a time, and whether the vehicle isscheduled to move after the change in the time as a change target aredesignated. When a date and a time (an occupied time due to movement ofthe vehicle or an inaccessible time except an occupant) in which avehicle moves decreases in the notification indicating change of amovement schedule, the rental management server 410 can simply changethe movement schedule and end the process flow. Accordingly, only thenotification indicating change of a movement schedule when the date andthe time at which the vehicle moves are changed or when the timeincreases is processed thereafter. Accordingly, S120 is an example of aprocess of causing the rental management server 410 to receive a requestfor change of the movement schedule of the vehicle of the owner from anon-movement schedule to a movement schedule at a date and timeoverlapping the date and time at which rental of the vehicle is reservedfrom the terminal of the owner of the vehicle.

Then, the rental management server 410 determines whether a vehicleinterior rental schedule is set at the date and the time as a changetarget (S121). When the vehicle interior rental schedule is not set atthe date and the time as a change target (NO in S121), the rentalmanagement server 410 changes the movement schedule information (S122)and ends the process flow.

On the other hand, when the vehicle interior rental schedule is set atthe date and the time as a change target (YES in S121), the rentalmanagement server 410 searches for alternative vehicles from the clustermember table (FIG. 6) (S123). Then, the rental management server 410searches for an available alternative vehicle at the date and the timeas a change target from the searched-for alternative vehicles. Then,when there is an available alternative vehicle at the date and the timeas a change target (YES in S124), the rental management server 410changes the vehicle interior rental schedule (S125). That is, rental ofthe interior of the alternative vehicle is reserved at the date and thetime as a change target. The reservation for rental of the interior ofthe vehicle which has been originally reserved at the date and the timeas a change target is cancelled. Accordingly, the processes of S123 toS125 is an example of a process of causing the rental management server410 to determine one vehicle from vehicles belonging to the same groupas the vehicle which is a transportation destination as an alternativevehicle.

The rental management server 410 acquires terminal authenticationinformation used for authentication in the key unit 100 of thealternative vehicle from the central server 400. Then, the rentalmanagement server 410 transmits the information for identifying thealternative vehicle and the terminal authentication information used forauthentication in the key unit 100 to the deliverer terminal 220 and thereceiver terminal 230 (S126). Similarly to FIGS. 16A and 16B, the rentalmanagement server 410 may transmit the terminal authenticationinformation to the deliverer terminal 220 when a request for unlockinginformation is issued at the time of delivery. Similarly to FIGS. 16Aand 16B, the rental management server 410 may transmit the terminalauthentication information to the receiver terminal 230 when thedelivery has been completed. The process of S126 is an example of aprocess of causing the rental management server 410 to controltransmission of the information for identifying the selected alternativevehicle and access permission information for permitting an access tothe interior of the alternative vehicle to a terminal of a service user.

Then, the rental management server 410 counts up a monthly frequency ofvehicle interior rental change due to change of a schedule in the ownerevaluation table and reduces the incentive points of the owner of thecorresponding vehicle (S127). The method of reducing the incentivepoints is not particularly limited. For example, a fixed value may besubtracted therefrom or points corresponding to a predeterminedproportion may be decreased. The monthly frequency of vehicle interiorrental change due to change of a schedule is an example of a rate atwhich rental of a reserved vehicle could not be implemented due tochange of a movement schedule. Accordingly, through the process of S127,the rental management server 410 can be said to determine the incentivepoints which are offered to an owner of a reserved vehicle based on arate at which rental of the reserved vehicle could not be implementeddue to change of a movement schedule.

On the other hand, when there is no available alternative vehicle at thedate and the time as a change target (NO in S124), the rental managementserver 410 returns a response indicating that the movement schedule isnot to be changed to the owner terminal 210 (S128). When the movementschedule is not to be changed, the owner of the vehicle performs theprocedure based on conventions of the carsharing service provided by theinformation system. For example, an owner of a vehicle contacts amanager of the carsharing service or the like and consults about apreferable measure.

<Advantages of Second Embodiment>

As described above, in the information system according to the secondembodiment, the rental management server 410 receives a notificationindicating that a capacity of baggage to be delivered by a deliverer isgreater than the capacity of the interior of a vehicle as a deliverydestination, selects an alternative vehicle belonging to the samecluster as the vehicle which is the delivery destination, and notifiesthe deliverer terminal 220. A cluster is formed by vehicles of which aparking lot is located near a parking lot address of each vehicle.Accordingly, by causing the rental management server 410 to select avehicle belonging to the same cluster as the vehicle which is a deliverydestination, there is a high likelihood that a second-best method willbe performed even when a situation in which the capacity of baggage tobe delivered is greater than the capacity of the interior of the vehiclewhich is a delivery destination. That is, the rental management server410 can select an alternative vehicle from vehicles near the deliverydestination as much as possible and can set the selected alternativevehicle as a new delivery destination. As a result, the informationsystem according to the second embodiment can reduce the frequency inwhich a deliverer returns with a delivery object due to an over-capacityand can enable a receiver to receive the delivery object near theoriginal delivery destination. For example, by searching for analternative vehicle from the vehicles belonging to the same cluster inthe order of getting apart from the vehicle as the original deliverydestination, the information system can improve convenience for adeliverer and a receiver.

In the second embodiment, when an activity schedule of an owner ischanged and the owner newly wants to drive the vehicle, the owner of thevehicle can drive the vehicle even when the interior of the vehicle hasbeen reserved at the date and the time at which driving of the vehicleis necessary. That is, the owner can receive a service of searching foran alternative vehicle using the rental management server 410 by settingchange of the movement schedule in the rental management server 410.When an alternative vehicle is searched for, the rental managementserver 410 can change the vehicle interior rental schedule such that theinterior of the alternative vehicle is provided instead of the originalvehicle. Accordingly, with the information system, it is possible toincrease a likelihood that an owner of a vehicle will be able to use thevehicle even when the owner of the vehicle has approved rental of theinterior of the vehicle in the carsharing service and the interior ofthe vehicle has been already reserved by another user. The informationsystem can flexibly cope with a case in which urgent business occurs inan owner of a vehicle and the owner wants to use the vehicle. Such aservice of searching for an alternative vehicle is advantageous whenbaggage has been already delivered (but not picked up) to the interiorof a vehicle which is used as a home delivery box (or a pickup box).When it is necessary to drive the vehicle in a state in which anotheruser's baggage has been delivered and has not been received by areceiver, the owner can requests the rental management server 410, whichperforms the process of S120 in FIG. 18, to change the movementschedule. The owner of the vehicle can get previous permission of ascheduled receiver of the baggage and transfer the baggage delivered tothe vehicle to an alternative vehicle which is provided by the rentalmanagement server 410. Accordingly, for example, even when urgentbusiness occurs in the owner of the vehicle, it is possible to decreasea likelihood that a scheduled receiver of baggage will not be able toreceive the baggage in the interior of the vehicle.

When the interior of a vehicle has been already reserved by another userand the interior of an alternative vehicle is provided instead of theinterior of the vehicle due to change of a movement schedule of thevehicle, an activity schedule of the owner of the vehicle, or the like,the incentive points of the owner are decreased. Accordingly, in thecarsharing service provided by the information system, an owner of avehicle takes consideration such that rental of the interior of thevehicle in the carsharing service is not affected by schedule change ofthe owner as much as possible and thus it is possible to provide astable carsharing service. In the information system, by preferentiallyselecting a vehicle of an owner having agreed to provision of a movementschedule or a vehicle of an owner having a high number of incentivepoints as a delivery destination, it is possible to select a vehiclewith high certainty as a delivery box for home delivery.

Third Embodiment

In the first and second embodiment, an example of a process flow in theinformation system using the interior of a vehicle as a home deliverybox of a delivery destination of home delivery has been described. Inthe second embodiment, a process of requesting switching from a vehiclein the same cluster to an alternative vehicle when the interior of avehicle has an over-capacity at the time of delivery or when an owner ofa vehicle wants to use the vehicle of which the interior has beenalready reserved for driving has been described.

In the third embodiment, an example of a process flow of designating acluster into which vehicles are grouped and formed as a deliverydestination of home delivery or a delivery destination of a purchasedproduct in online shopping or the like will be described. When adelivery destination can be designated as a cluster, the deliverydestination can be selected from a plurality of vehicles located in acertain limited range at the date and time at which actual delivery isperformed and control can be performed such that the delivery iscompleted even if the date and time of delivery is not clearly fixed.Accordingly, it is possible to flexibly deliver a delivery object withconvenience for a home delivery company and a receiver.

FIGS. 19A and 19B are sequence charts of the information systemaccording to the third embodiment. FIGS. 19A and 19B illustratetransmission and reception of information between a onboard device 10Amounted in a vehicle 10, a receiver terminal 230 of a receiver whoreceives a home delivery object, a deliverer terminal 220 of a homedelivery company, a home delivery business server 430, a rentalmanagement server 410, and a central server 400. In FIGS. 19A and 19B,the rental management server 410 and the home delivery business server430 are separated from each other in comparison with FIGS. 16A and 16Baccording to the second embodiment. However, in the third embodiment,the process of the home delivery business server 430 may be incorporatedinto the rental management server 410 and both may operate as a unifiedbody. The configuration and operation in the third embodiment exceptthat a delivery destination can be designated as a cluster and therental management server 410 and the home delivery business server 430are separated are the same as in the first and second embodiments.Therefore, the same elements in the third embodiment as in the first andsecond embodiments will be referred to by the same reference signs anddescription thereof will not be repeated. In FIGS. 19A and 19B, the homedelivery business server 430 is illustrated, but the processes in thethird embodiment are not limited to the processes associated with thehome delivery business server 430 and the configuration of the thirdembodiment can be applied to a business server for an online shoppingservice and other business servers.

In the process flow of the information system, for example, in an onlineshopping service, the receiver terminal 230 transmits a delivery requestincluding a communication address of the receiver terminal 230 on thenetwork N1 and a delivery destination of a purchased product to the homedelivery business server 430. In another example, the receiver terminal230 sets a delivery destination address and a confirmation result of ascheduled (desired) delivery date and time or the like in the rentalmanagement server 410 from the communication address of the receiverterminal 230 on the network N1, for example, in response to aconfirmation request notification of the delivery date and time from thehome delivery business server 430 (U11). Here, a receiver may not fixthe scheduled delivery date and time or the desired delivery date andtime. An example of such a case is a case in which a schedule forsecuring an ordered product cannot be clearly fixed due to circumstancesof an online shopping company. Another example thereof is a case inwhich a schedule for receiving a delivery object cannot be clearly fixedby a receiver.

When the scheduled delivery date and time or the desired delivery dateand time cannot be fixed, the rental management server 410 does notspecify the scheduled delivery date and time, designates a surroundingarea of the delivery destination address of the purchased product in theonline shopping, and requests a reservation for the interior of avehicle to the rental management server 410 (U12). The reservationrequest for the interior of a vehicle in U12 is an example of a serviceusage request using a vehicle as a delivery destination of baggage. Therental management server 410 receives the reservation request for theinterior of a vehicle. Unlike the second embodiment, when the scheduleddelivery date and time is not clearly fixed, the rental managementserver 410 returns and presents a response including a cluster ID and anaddress of an available cluster around the delivery destination addressand other information to the receiver terminal 230 via the home deliverybusiness server 430 with reference to the cluster definition table(U13). The process of U13 of causing the rental management server toreceive the reservation request for the interior of a vehicle is anexample of receiving a service usage request including a desired rentalregion of the interior of a vehicle which is supplied for the vehiclerental service. The process of causing the rental management server 410to return a response in U13 is an example of specifying a group ofvehicles associated with the desired rental region and providinginformation on the specified group.

When a receiver performs acknowledgement via a GUI of the receiverterminal 230 (U14), the reservation for the cluster is registered in therental management server 410 via the home delivery business server 430(U15). The rental management server 410 may promote the receiver to setan approximate reservation period via the receiver terminal 230 andcontrol the reservation such that the reservation is not concentrated ona specific cluster in a specific period. When the reserved cluster isconfirmed by the receiver terminal 230, the reservation for the clusteris registered in the rental management server 410, and the scheduleddelivery date and time is fixed, the home delivery business server 430notifies the deliverer terminal 220 of the information indicating thedelivery destination (U16).

When the scheduled delivery date and time is within a predetermined time(for example, within one day), the deliverer terminal 220 designates acluster ID as a delivery destination and requests the rental managementserver 410 to transmit vehicle information for identifying a vehicle asan actual delivery destination belonging the cluster and terminalauthentication information for unlocking a gate or door to the interiorof the vehicle via the home delivery business server 430 (U17). Therequest in U17 is an example of an access request to the group which isissued from a terminal of a service user in charge of transportation ofbaggage within a predetermined period from the scheduled transportationdate and time after the scheduled transportation date and time at whichtransportation of baggage is performed has been fixed. When vehicleinformation and terminal authentication information are requested fromthe deliverer terminal 220, the rental management server 410 firstselects one vehicle which is not reserved at the scheduled delivery dateand time in the rental schedule DB D15 (see FIG. 11) from vehiclesbelonging to the designated cluster ID (U18). When there is a pluralityof vehicles which are not reserved at the scheduled delivery date andtime, the rental management server 410 selects a vehicle as follows. Theprocess of U18 is an example of selecting one vehicle from the vehiclesbelonging to the group.

The method of selecting a vehicle belonging to a cluster ID is the sameas in the first and second embodiments (for example, the process of S8performed by the rental managing unit F15 in FIG. 12). The rentalmanagement server 410 may set the order of getting apart from theaddress designated by a vehicle interior rental application as arecommended order. The rental managing unit F15 may set a recommendedorder in which a vehicle of an owner having agreed to provision of amovement schedule. The rental managing unit F15 may sort vehicles in theorder of decreasing the incentive points from an owner having a highestnumber of incentive points in the owner evaluation table (see FIG. 8)and set the sorted order as a recommended order. These conditions may beweighted and combined and the weighted order may be set as therecommended order. Then, the rental management server 410 selects onemost preferable vehicle in the recommended order as a deliverydestination from the vehicles belonging to the cluster.

The rental management server 410 designates a vehicle ID of a vehicleselected as the delivery destination, an owner ID of the vehicle, and apassword and requests the central server 400 to transmit terminalauthentication information (U19). Here, the terminal authenticationinformation is information which is used for authentication in the keyunit 100 to correspond to device authentication information of the keyunit 100, similarly to the first embodiment.

Then, the central server 400 issues the terminal authenticationinformation which is used for authentication in the key unit 100registered in correlation with the designated owner ID and thedesignated vehicle ID (U20). Then, the rental management server 410receives the terminal authentication information from the central server400 transmits information (vehicle information) for identifying thevehicle selected as the delivery destination and the received terminalauthentication information to the deliverer terminal 220 via the homedelivery business server 430 or directly (U21). The processes of U19 toU21 are an example of selecting one vehicle from the vehicles belongingto the group and controlling transmission of information for identifyingthe selected vehicle and access permission information for permitting anaccess to the interior of the selected vehicle to the service userterminal.

The deliverer terminal 220 receives the vehicle information foridentifying the vehicle serving as a home delivery box of the deliverydestination and the terminal authentication information which is aone-time key from the rental management server 410 via the home deliverybusiness server 430 or directly (U22). Then, the deliverer moves to theparking lot address or the parking lot position of the vehicledesignated as the delivery destination using a car navigation functionor the like and specifies the vehicle from the registration number, thevehicle manufacturer, the popular name of the vehicle (a vehicle model),and the color which identify the vehicle. The deliverer terminal 220requests the key unit 100 mounted in the vehicle 10 designated as thedelivery destination for authentication using the received terminalauthentication information and performs an unlocking operation inresponse to the deliverer's operation (U23). Then, the key unit 100 ofthe onboard device 10A performs the requested authentication and unlocksthe gate or door to the interior of the vehicle 10 in accordance with anunlocking request when the authentication has succeeded (U24).

When the gate or door to the interior of the vehicle 10 is unlocked, thedeliverer opens the gate or door to the interior of the vehicle. Afterthe gate or door to the interior of the vehicle has been opened, thedeliverer completes the delivery when a delivery object can beaccommodated in the interior of the vehicle. The deliverer terminal 220notifies the home delivery business server 430 of a delivery completionnotification in response to the deliverer's operation (U25). However,when the volume or size of the delivery object is greater than theallowable capacity of the interior of the vehicle (YES in U24), a nextvehicle is necessary. Therefore, when the capacity of the interior ofthe vehicle is insufficient and a next vehicle is necessary, thedeliverer terminal 220 designates the original cluster ID and requeststhe rental management server 410 for a next vehicle via the homedelivery business server 430 or directly in response to the deliverer'soperation (U25). Then, the rental management server 410 searches foranother vehicle from the same cluster (U26). When a next vehicle issearched for, the rental management server 410 returns the process flowto U19 and requests transmission of terminal authentication informationused for authentication of the next vehicle.

Although not illustrated in FIGS. 19A and 19B, the process when a nextvehicle is not searched for in the process of U21 is the same as theprocess of searching for an alternative vehicle in FIGS. 16A and 16B.The reason why an alternative vehicle is searched for in FIGS. 16A and16B and a next vehicle is searched for in FIGS. 19A and 19B is that whenthe capacity of the interior of a vehicle as a delivery destination isinsufficient in FIGS. 19A and 19B, the deliverer may distribute andaccommodate a delivery object in a plurality of vehicles belonging tothe cluster. In this case, the deliverer terminal 220 or the homedelivery business server 430 can notify the receiver terminal 230 ofinformation for identifying the vehicles in which the delivery object isdistributed and accommodated. In the second embodiment, when theinterior of a vehicle is in an over-capacity, the deliverer maydistribute and accommodate the delivery object in a plurality ofvehicles belonging to the cluster instead of substituting the deliverydestination with an alternative vehicle.

When the deliverer terminal 220 notifies the rental management server410 of the delivery completion notification in U25 (U27), the delivererterminal 220 invalidates the terminal authentication information, forexample, by deleting the terminal authentication information stored inthe deliverer terminal 220 (U28). The processes after the delivery hasbeen completed are the same as the processes of T24 and subsequentthereto in FIGS. 16A and 16B and thus description thereof will not berepeated.

As described above, with the information system according to the thirdembodiment, vehicles can be grouped into clusters and an online shoppinguser or a receiver of home delivery can designate a cluster as adelivery destination. The cluster can be said to be a group of vehicleswhich is formed based on at least one of locations of parking lots atwhich vehicles are parked, movement ranges of the vehicles, activityranges of owners of the vehicles, and friendship ranges of the owners.Accordingly, in a carsharing service in which the interior of a vehicleis rented, a user can flexibly use the carsharing service by designatinga cluster as a rental destination. For example, it is possible toincrease a likelihood that a deliverer will complete delivery to one ormore other vehicles near the delivery destination and to decrease alikelihood of redelivery even when the interior of a specific vehicle isaccidentally in an over-capacity state. It is also possible to increasea likelihood that a receiver will receive a delivery object in a vehiclenear the original delivery destination early. Even when a scheduleddelivery date and time is not fixed, an online shopping user can enjoythe online shopping easily without being conscious of the scheduleddelivery date and time by first designating a cluster as a latentdelivery destination. In actual delivery, it is possible toappropriately select a vehicle in a cluster in the order preferable forthe deliverer and the receiver such as the order of getting apart fromthe delivery destination address at which the receiver lives or theorder of decreasing the incentive points due to provision of a movementschedule or observation of the movement schedule in cooperation of thedeliverer terminal 220 with the home delivery business server 430, therental management server 410, and the central server 400, and to improveconvenience for the deliverer and the receiver.

<Modified Example 1 of Embodiment>

In the above-mentioned embodiments, an example in which a vehicle 10 isunlocked by the locking/unlocking device 300 when the authenticationprocess in the key unit 100 has succeeded has been described above, butthe process in the key unit 100 may be performed by thelocking/unlocking device 300 in Modified Example 1 of the embodiments.That is, the locking/unlocking device 300 may include a control unit(ECU) that authenticates authentication information received from theuser terminal 200, and the control unit may transmit an unlockingcommand or a locking command to the body ECU 304 via an onboard networksuch as a CAN when the authentication of the user terminal 200 hassucceeded. With the carsharing system according to Modified Example 1,baggage can be received by a receiver as a third party with a simpleconfiguration without installing the key unit 100.

<Modified Example 2 of Embodiment>

In the above-mentioned embodiments, a user terminal 200 receivesauthentication information from the central server 400, alocking/unlocking signal is transmitted from the key unit 100 to thelocking/unlocking device 300 when the user terminal 200 is authenticatedbased on the received authentication information, and a vehicle 10 islocked and unlocked. In Modified Example 2 of the embodiments, theauthentication information is not information for authenticating theuser terminal 200 but includes information of a key ID for locking andunlocking the vehicle 10.

In this case, the user terminal 200 receives authentication informationincluding a key ID for locking and unlocking the vehicle 10 from thecentral server 400, and transmits the received key ID to thelocking/unlocking device 300 along with a locking/unlocking signal. Thelocking/unlocking device 300 compares the received key ID with a key IDstored in advance in the locking/unlocking device 300 and locks andunlocks the vehicle 10 when both key IDs coincide with each other. Thekey ID may be encrypted and transmitted between the user terminal 200and the central server 400 or the locking/unlocking device 300. Thecentral server 400 may generate a one-time key, for example, byencrypting the key ID along with time information using a predeterminedalgorithm. The locking/unlocking device 300 can decrypt the receivedone-time key using the same algorithm as in the central server 400 andcompare the decrypted one-time key with the key ID stored in advance inthe locking/unlocking device 300. The one-time key may be transmittedfrom the central server 400 to the rental management server 410 andtransmitted from the rental management server 410 to the user terminal200. In any case, the user terminal 200 can invalidate the one-time keyby deleting the one-time key when a predetermined time has elapsed fromreception of the one-time key.

Since the one-time key generated from the key ID and the timeinformation is included in the authentication information, the centralserver 400 can generate authentication information which is temporarilyvalid for each received request and transmit the generatedauthentication information to the user terminal 200.

<Modified Example 3 of Embodiment>

In Modified Example 2 of the embodiments, the central server 400transmits authentication information for the user terminal 200corresponding to fixed authentication information specific to the keyunit 100 or a key ID stored in advance in the locking/unlocking device300 of the vehicle 10 to the user terminal 200. However, theauthentication information between the user terminal 200 and the keyunit 100 is not limited thereto. In Modified Example 3 of theembodiments, for example, when a request for terminal authenticationinformation is received from the user terminal 200, the central server400 may generate new terminal authentication information and issue thenew terminal authentication information to the user terminal 200. Inthis case, the central server 400 can store device authenticationinformation for the key unit 100 corresponding to the new terminalauthentication information for the user terminal 200 to the key unit 100via an onboard communication device (not illustrated) communicating withthe network N1 connected to the central server 400. In this case, thekey unit 100 can be connected to the onboard communication device viathe CAN or the like. Here, the central server 400 may generate newterminal authentication information based on identification informationfor identifying a vehicle 10 and time information and transmit the newterminal authentication information and the time information to the userterminal 200. In this case, the key unit 100 can also generate newdevice authentication information using the same algorithm as in thecentral server 400. The user terminal 200 can transmit the newauthentication information and the time information to the key unit 100and be authenticated.

<Others>

In the carsharing system 1 according to the embodiments and the modifiedexamples, regarding locking/unlocking of the vehicle 10, it is assumedthat unlocking/locking of only a cargo compartment door (gate) iscontrolled, unlocking/locking of a passenger compartment is notcontrolled but the passenger compartment is maintained in a locked statein consideration of security. In a vehicle 10 having a body structure inwhich a cargo compartment and a passenger compartment are notpartitioned from each other, for example, a vehicle 10 of a one-boxtype, the passenger compartment can be accessed by unlocking the cargocompartment door and thus an owner of a vehicle or the like may haveconcern in security.

Therefore, in a vehicle 10 in which a cargo compartment and a passengercompartment are not partitioned from each other, a moving image of thepassenger compartment is captured by a drive recorder or the like thatcan image the passenger compartment when the cargo compartment door isopened, and it can be determined whether there is invasion from thecargo compartment to the passenger compartment based on the capturedmoving image. For example, when it is determined that there is invasionfrom the cargo compartment into the passenger compartment, an ECU thatcontrols the drive recorder performs storage of the captured image,operation of an onboard alarm, notification of a provider, notificationof a user, and the like. On the other hand, when it is determined thatthere is no invasion into the passenger compartment, the ECU may deletethe captured moving image at a time point at which the cargo compartmentdoor is closed and a locking operation is performed. The drive recordermay transmit the captured moving image to the owner terminal 210regardless of whether there is invasion into the passenger compartmentas part of a user service.

In the first to third embodiments, the processes which are performed bythe information system for supporting implementation of a vehicleinterior rental service have been described. However, the processeswhich are performed by the information system in the first to thirdembodiments are not limited to the vehicle interior rental service. Forexample, the processes which are performed by the information system inthe first to third embodiments can also be applied to a rental servicewith movement of a vehicle.

What is claimed is:
 1. A carsharing system comprising: circuitryconfigured to: receive, from a user, a usage request for requesting areservation for use of a vehicle which is supplied for a vehicle rentalservice; determine whether there is a first vehicle that is suitable forthe usage request based on activity schedule information in which anactivity schedule of an owner of the vehicle is set; permit thereservation for use of the vehicle when the circuitry determines thatthere is the first vehicle; receive a change request for changing theactivity schedule information after permitting the reservation; anddetermine whether there is an alternative vehicle that is suitable forthe usage request, the alternative vehicle being different from thefirst vehicle.
 2. The carsharing system according to claim 1, whereinthe usage request includes a desired rental schedule which is a schedulein which the user desires rental of the vehicle, and the circuitry isconfigured to: store reservation schedule information indicating astatus of the reservation for use of the vehicle; acquire movementschedule information indicating a movement schedule of the vehicle; andprovide information on vehicle of which both the reservation scheduleinformation and the movement schedule information satisfy the desiredrental schedule.
 3. The carsharing system according to claim 2, whereinthe desired rental schedule includes a scheduled transportation date andtime, transportation of baggage being planned to be performed at thescheduled transportation date and time, and the circuitry is configuredto: select a selected vehicle which is available at the scheduledtransportation date and time; and set a reservation for use of theselected vehicle at the scheduled transportation date and time in thereservation schedule information.
 4. The carsharing system according toclaim 3, wherein the circuitry is configured to control transmitting, toa terminal of a service user associated with the transportation of thebaggage, information for identifying the selected vehicle and accesspermission information for permitting an access to interior of theselected vehicle.
 5. The carsharing system according to claim 4, whereinthe usage request includes receiver terminal information for specifyingan address of a terminal of a receiver who receives the baggage, and thecircuitry is configured to control transmitting, to the terminal of thereceiver, the information for identifying the selected vehicle and theaccess permission information for permitting an access to the interiorof the selected vehicle.
 6. The carsharing system according to claim 4,wherein the vehicles which are supplied for the vehicle rental serviceare grouped based on geographical position relationships correlated withthe vehicles respectively, and the circuitry is configured to: determineone vehicle of the vehicles as an alternative vehicle, the one vehiclebelonging to same group as a vehicle which is a transportationdestination when a notification is received from the terminal of theservice user, the notification indicating that an over-capacity hasoccurred, the over-capacity being a situation in which baggage to betransported is not able to be accommodated in the interior of thevehicle which is the transportation destination; and controltransmitting, to the terminal of the service user, the information foridentifying the alternative vehicle and the access permissioninformation for permitting an access to the interior of the alternativevehicle.
 7. A carsharing method comprising: causing circuitry toreceive, from a user, a usage request for requesting a reservation foruse of a vehicle which is supplied for a vehicle rental service; causingthe circuitry to determine whether there is a first vehicle that issuitable for the usage request based on activity schedule information inwhich an activity schedule of an owner of the vehicle is set; causingthe circuitry to permit the reservation for use of the vehicle when theit is determined that there is the first vehicle; causing the circuitryto receive a change request for changing the activity scheduleinformation after permitting the reservation; and causing the circuitryto determine whether there is an alternative vehicle that is suitablefor the usage request, the alternative vehicle being different from thefirst vehicle.
 8. The carsharing method according to claim 7, whereinthe usage request includes a desired rental schedule which is a schedulein which the user desires rental of the vehicle, and the method furthercomprises: causing the circuitry to store reservation scheduleinformation indicating a status of the reservation for use of thevehicle; causing the circuitry to acquire movement schedule informationindicating a movement schedule of the vehicle; and causing the circuitryto provide information on vehicle of which both the reservation scheduleinformation and the movement schedule information satisfy the desiredrental schedule.
 9. The carsharing method according to claim 8, whereinthe desired rental schedule includes a scheduled transportation date andtime, transportation of baggage being planned to be performed at thescheduled transportation date and time, and the method furthercomprises: causing the circuitry to select a selected vehicle which isavailable at the scheduled transportation date and time; and causing thecircuitry to set a reservation for use of the selected vehicle at thescheduled transportation date and time in the reservation scheduleinformation.
 10. The carsharing method according to claim 9, furthercomprising causing the circuitry to transmit, to a terminal of a serviceuser associated with the transportation of the baggage, information foridentifying the selected vehicle and access permission information forpermitting an access to interior of the selected vehicle.
 11. Thecarsharing method according to claim 10, wherein the usage requestincludes receiver terminal information for specifying an address of aterminal of a receiver who receives the baggage, and the method furthercomprises causing the circuitry to transmit, to the terminal of thereceiver, the information for identifying the selected vehicle and theaccess permission information for permitting an access to the interiorof the selected vehicle.
 12. The carsharing system according to claim10, wherein the vehicles which are supplied for the vehicle rentalservice are grouped based on geographical position relationshipscorrelated with the vehicles respectively, and the method furthercomprises: causing the circuitry to determine one vehicle of thevehicles as an alternative vehicle, the one vehicle belonging to samegroup as a vehicle which is a transportation destination when anotification is received from the terminal of the service user, thenotification indicating that an over-capacity has occurred, theover-capacity being a situation in which baggage to be transported isnot able to be accommodated in the interior of the vehicle which is thetransportation destination; and causing the circuitry to transmit, tothe terminal of the service user, the information for identifying thealternative vehicle and the access permission information for permittingan access to the interior of the alternative vehicle.
 13. Anon-transitory computer readable medium that stores an executableprogram, wherein the program, when executed, causes a carsharing systemto execute processing comprising: receiving, from a user, a usagerequest for requesting a reservation for use of a vehicle which issupplied for a vehicle rental service; determining whether there is afirst vehicle that is suitable for the usage request based on activityschedule information in which an activity schedule of an owner of thevehicle is set; permitting the reservation for use of the vehicle whenthe it is determined that there is the first vehicle; receiving a changerequest for changing the activity schedule information after permittingthe reservation; and determining whether there is an alternative vehiclethat is suitable for the usage request, the alternative vehicle beingdifferent from the first vehicle.
 14. The non-transitory computerreadable medium according to claim 13, wherein the usage requestincludes a desired rental schedule which is a schedule in which the userdesires rental of the vehicle, and the program further comprises:storing reservation schedule information indicating a status of thereservation for use of the vehicle; acquiring movement scheduleinformation indicating a movement schedule of the vehicle; and providinginformation on vehicle of which both the reservation scheduleinformation and the movement schedule information satisfy the desiredrental schedule.
 15. The non-transitory computer readable mediumaccording to claim 14, wherein the desired rental schedule includes ascheduled transportation date and time, transportation of baggage beingplanned to be performed at the scheduled transportation date and time,and the program further comprises: selecting a selected vehicle which isavailable at the scheduled transportation date and time; and setting areservation for use of the selected vehicle at the scheduledtransportation date and time in the reservation schedule information.16. The non-transitory computer readable medium according to claim 15,wherein the program further comprises transmitting, to a terminal of aservice user associated with the transportation of the baggage,information for identifying the selected vehicle and access permissioninformation for permitting an access to interior of the selectedvehicle.
 17. The non-transitory computer readable medium according toclaim 16, wherein the usage request includes receiver terminalinformation for specifying an address of a terminal of a receiver whoreceives the baggage, and the program further comprises transmitting, tothe terminal of the receiver, the information for identifying theselected vehicle and the access permission information for permitting anaccess to the interior of the selected vehicle.
 18. The non-transitorycomputer readable medium according to claim 16, wherein the vehicleswhich are supplied for the vehicle rental service are grouped based ongeographical position relationships correlated with the vehiclesrespectively, and the program further comprises: determining one vehicleof the vehicles as an alternative vehicle, the one vehicle belonging tosame group as a vehicle which is a transportation destination when anotification is received from the terminal of the service user, thenotification indicating that an over-capacity has occurred, theover-capacity being a situation in which baggage to be transported isnot able to be accommodated in the interior of the vehicle which is thetransportation destination; and transmitting, to the terminal of theservice user, the information for identifying the alternative vehicleand the access permission information for permitting an access to theinterior of the alternative vehicle.